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CAUSE, the Professional Association for Computing and Information Tech- 
nology in Higher Education, helps colleges and universities strengthen and 
improve their computing, communications, and information services, both 
academic and administrative. The association also helps individual members 
develop as professionals in the field of higher education computing and infor- 
mation technology. 

Formerly known as the College and University Systems Exchange, CAUSE 
was organized as a volunteer association in 1962 and incorporated in 1971 
with twenty-five charter member institutions. In the same year the CAUSE 
National Office opened in Boulder, Colorado, with a professional stafFto serve 
the membership. Today the association serves almost 2,000 individuals from 
730 campuses representing nearly 500 colleges and universities, and 31 
sustaining member companies. 

CAUSE provides member institutions with many services to increase the ef- 
fectiveness of their computing environments, including: the Administrative 
Systems Query (ASQ) Service, which provides to members informationabout 
typical computing practices among peer institutions from a data base of 
member institution profiles; the CAUSE Exchange Library, a clearinghouse 
for documents and systems descriptions made available by members through 
CAUSE; association publications, including a bi-monthly newsletter, CAUSE 
Information, the professional magazine, CAUSE I EFFECT, and monographs 
and professional papers; workshops and seminars; and the CAUSE National 
Conference. 

We encourage you to use CAUSE to support your own efforts to strengthen 
your institution's management and educational capabilities through the 
effective use of computing and information technology. 
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INTRODUCTION 

As professionals in an always-exciting field, we are constantly facing challenges to blend new infor- 
mation technologies into our institutions* It is important for higher education to develop environ- 
ments that promote the use of information technology for strategic advantages, that allow faculty, 
staff, and students to benefit from existing technology, and that stimulate the discovery of new 
opportunities. 

The 1987 CAUSE National Conference, with its theme "Leveraging Information Technology,* offered 
the opportunity for us to share, exchange, and learn of new developments in information technology 
to improve and enhance our environments* The CAUSE87 program was designed to allow the fullest 
possible discussion of issues related to these new developments* Seven concurrent tracks with 49 
selected presentations covered important issues in general areas of policy and planning, manage- 
ment, organization, and support services, as well as in the specialized areas of communications, 
hardware/software strategies, and outstanding applications. 

To expand opportunities for informal interaction, some changes were made in the program schedule. 
CAUSE Constituent Groups met the day before the conference, as they did in 1986, but were given 
opportunities to meet again during the conference. Current Issues Sessions were moved to Thursday 
afternoon to provide some flexibility with time, encourage interactive participation, and extend 
opportunities to continue discussions with colleagues. Vendor workshops were offered for the first 
time this year, the day before the conference. The Wednesday afternoon schedule accommodated 
continued vendor workshops, vendor suite exhibits, and concurrent vendor sessions. 

David P. Roselle, President of the University of Kentucky, set the tone for CAUSE87 with a Wednes- 
day morning opening presentation expressing his commitment to the value of information technology 
in higher education. John G. Kemeny, past president of Dartmouth College and currently Chairman 
of the Board of True BASIC, Inc., spoke during Thursday's luncheon of new developments in comput- 
ing for classroom learning. The concluding general session, Friday's Current Issues Forum, offered 
an exchange of philosophies about making optimal use of technologies on our campuses. 

We were extremely fortunate to be at Innisbrook, a resort with outstanding conference facilities and 
great natural beauty (and weather)— a real distillation of the best of Florida. 

Almost 800 people attended CAUSE87. Many of them described the conference, in their evaluation 
forms, as stimulating, informative, and memorable. We hope this publication of the substance of 
CAUSE87 will be a continuing resource, both for conference-goers and for those who will be reading 
about the conference offerings for the first time. 



Wayne Donald 
CAUSE87 Chair 
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ABSTRACT 

The University of Hartford had the necessary infrastructure 
in place to capitalize on its investment in four major 
integrated systems, when the current data base vendor and 
application software vendor joined to offer a package of 
software products. Project goals were to upgrade to an 
advanced relational data base management system, to provide 
on-line management summary inquiry facilities and a new 
query facility for direct on-line access by end users, and 
to install a fourth generation language. Since this would 
be the first installation of these products in an 
operational environment, flexibility of plans and execution 
would be required. 

The value of having a solid foundation of stabilized 
systems, experienced staffs, cmmitment of management, 
flexible planning, and staff training is emphasized. 
Experience of migrating existing systems, conversion of the 
data bases, and impact upon computer operations will be 
discussed. 
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"INTEGRATED SYSTEMS - THE NEXT STEPS" 



Introduction 

In the early 1980 f s, the University of Hartford initiated a review of 
administrative systems and undertook the strategic project to install a 
series of advanced, integrated information systems. During an 18 month 
period, four administrative systems were installed. These systems were 
the accounts receivable (ARTS), human resources and payroll (HRIS) , 
financial information (IFIS) , and student information (ISIS) from the 
selected vendor, Systems and Computer Technology or SCT. About a year and 
a half later, these systems had been stabilized and the necessary 
infrastructure was in place and so that the University could consider a 
opportunity to capitalize on its investment. 

The opportunity focused on three areas: accessibility of data by 
management, replacement data base management system, and tools for easing 
the application system back log. The application systems had become 
integral to the operating departments but had not sufficiently satisfied 
the management information needs. The data base technology to allow 
secure access to the information was one need for an advanced data base 
management system. Another was that the current data base management 
system, TOTAL, was in a lf iteintenance status" and had to be replaced in any 
case. 

The project goals were to install an advanced relational data base 
management system (SUTRA) , an on-line management query system (part of 
Symmetry) , a new query facility (SPECTRA) for direct on-line access by 
management personnel and a fourth generation language (MANTIS) for 
analysts and programmers. 

It was recognized that this would be the first project of this type in a 
production environment, and therefore flexibility of plans and execution 
would be required. The solid foundation of operating experience and 
expertise of systems professionals and of management and supervisory end 
users was essential. The importance of experienced administrative and 
operating management in user departments must be emphasized. Not only 
were they very knowledgable in understanding their systems but also in 
system implementation projects. This first hand experience was a key 
resource in pursuing a very progressive project plan. They had 
successfully completed larger, more difficult projects before and so knew 
what to do and vihat trials and frustrations to expect. 

This paper focuses on the process of planning and execution rather than on 
technical details and broader institutional issues. 
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Background on the University cf Hartford 

The University of Hartford is an independent, comprehensive university 
which provides educational programs in the liberal arts end professional 
disciplines for undergraduate ~2 graduate students. There are 155 
graduate and undergraduate majors and degree programs. Most of the 4,200 
full-time undergraduate students come from the northeast part of the 
United States. In addition there are 7,000 others enrolled in part-time 
undergraduate and graduate programs and noncredit courses. 

The University campus is situated on a 230+ acre suburban setting in the 
greater Hartford area and has practically all of its facilities (colleges, 
dormitories, and administration buildings) on this contiguous piece 
of land. 

Computer and Human Resources 

In recognition of the University's investment in its integrated 
information systems, the computer resource had been upgraded to an IBM 
4381 (MVS operating system) with 130 terminals for the administrative 
users and the systems staff had been expanded and highly trained. 
Particularly important was the staffing in the application systems area, 
where a relatively small staff had attained a high level of expertise. 
This expertise was evidenced by the growing number of vendor supplied 
enhancements placed into production. 

Equally important was a knowledgable and experienced cemmunity of end 
users. A large number had participated in the original installation of the 
information systems and now used them in an operational environment. 

General Objectives and Goals 

With this foundation, the portfolio of information systems could then be 
viewed from a longer term and more flexible perspective as to what would 
be the next steps to build upon the institution's investment. The general 
goals were to enhance and improve the installed application systems and to 
build upon these systems and provide new strategic components (including 
direct access to the on-line data). The investment in the information 
systems could be leveraged by increasing the scope and increased strategic 
use of the information resources. 

The paths to accomplish these objectives were many. For example, vendor 
and in-house enhancements could be installed one by one to each of the 
systems or the current baseline software could be installed. A 
replacement data base management system was also a part of future plans. 

Status of Application Systems 

The four major information systems were advanced, integrated, on-line and 
batch applications from Systems and Computer Technology (SCT), that had 
been adapted to the University's environment. These adaptations varied 
from system to system. All of the systems had become an integral part in 
department operations. 
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Major Ad ministrative Application Systems 

Account Receivable Information System (ARIS) 

Human Resources Information System (HRIS) 
(human resource department functions, payroll) 

Integrated Financial Information System (IFIS) 
(fund accounting, budgeting, accounts payable) 

Integrated Student Information System (ISIS) 
(admissions, registration, financial aid, course catalogue, fee 
assessment, housing, academic history) 

In reviewing the portfolio, a number of aspects were investigated. Some 
of the more important areas were: 

Application Systems Portfolio Review 

Adaptation - Degree of adaptation versus vendor's current baseline 

s tability - Oomparative stability of the information system 

Data structure - Data structure for each information system 

("TOTAL" DEMS or VSAM files) 

BmefeipnajL^ - End user conclusion on the functionality of the 
current system as compared to the current baseline product 

Enhancements - Implementetion of the vendor supplied e nhancements 

Alternative - Feasibility and project estimates 

While i the level of expertise of tLa applications staff allowed a 
significant number of vendor supplied enhancements to be installed, the 
number of enhancements varied from system to system, in particular the 
human resources system (payroll portion) did not have the smooth operation 
J? 3 t ^S 3 r tt ? d 5 )hanoements to *» installed. Too many resources were 
diverted to handle the day to day operation of this (HRIS) system. With 
the excellent institutional foundation in both trained personnel and 
information systems, consideration could be given to upgrade certain 
systems to the most recr^t releases and thus bypass the enhancement by 
enhancement process. J 

Another candidate was the Accounts Receivable system (ARIS) ; however the 
extent of adaptations gave pause to the consideration of upgrading that 
system for the time being. The financial system (IFIS) was the most 
stabile of the systems. However IFIS was not the TOTAL version as were 
all of the others but the VSAM version. The largest system of the four 
systems by far was (and is) the student information system (ISIS), which 
was stabile and had a number of major enhancements installed. For ISIS, 
the Tuition Assessment portion had been greatly expanded by the University 
to provide a very flexible tuition and fee assessment module. 

- 3 - 
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Major Lom Rame plan Oanponents 

It is well to note the difference between an upgrade to a baseline and an 
installation of a software product for the first time. First time 
installations are massive projects when compared to the upgrade of 
existing software within a product line. In this context upgrades are 
updates and extensions, which are unlike first time installations. 

Of the systems, the human resources/payroll (HRIS) system was the most 
logical candidate for an upgrade and this project was begun in 1986 and 
finished in early 1987. The next most logical candidate for upgrading was 
the financial system (IPTS), but equally important was a replacement data 
base management system (DBMS) . 



Canponent 

Accounts Receivable (KRIS) 
Human Resource/Payroll (HRIS) 
Financial System (IFIS) 
Student System (ISIS) 
Data Base Management System 
Query Facility and 4GL 



Possible Plan - Current Status 
Upgrade to baseline - Deferred 

Upgrade to baseline - Completed 

Upgrade to baseline - In progress 

Major enhancements continuing 

Replacement DEMS - Completed 

Installation - Completed 



Data Base Management System - TOTAL to ? 

The data base management system being used to support the installed SCT 
systems was TOTAL from CENOCM Systems. This was a stable, "work horse" 
product; however it was an older technology that was destined to be 
superceded. Long term planning recognized that a new data base management 
system (DBMS) would have to be installed. It was also recognized that the 
currently installed TOTAL DEMS product had been highly tuned over the last 
few years. Furthermore, it was much simpler in operation and in 
performance tuning than any of the newer relational data base management 
systems being considered as replacement candidates. 

There were a number of major areas of comparison for a prospective data 
base management systems (DBMS). The data files, the job control 
statements (JCL), and the programs required a careful review of their 
migration options and risks associated with each candidate DEMS. Shis was 
especially true since neither the existing staff would be increased nor 
were there to be large expenditures available for contract programming 
support. 

Training of the Ccwputer Services staff would need to be done before the 
installation of any new product. Timing of any move to production would 
need to be considered very carefully as to allow for the majority of the 
work to be done outside of the heavy usage periods in the academic 
calendar and to allcw for substantial timing of any new DEMS before the 
next such heavy usage^ period occurred. 
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DBMS Selection Criteria 

i!^!^? 0 ?!? £ Sfif." To . be a proven producfc with a significant number 
of sites in production with COBOL programs. 

aT^ftr^f^-^ ^ ^ securit y to the new environment 
as well as the flexibility to return to the old. 

5S*Sw!S Si " Not rec 2 aire lo ? ic changes to the existing 
application programs. ^ 

Functional Transparency - No end user training requirea. 

. performance - To be at least as good as with the current DBMS. 

Ad^nc^Itelational Sg fflgj gy - To provide immediate benefits while 
providing a basis for the future* 

Ad Hoc Query - To allow direct access by end user staff, while 
maintaining confidentiality and integrity of the data base files. 

4SL - A fourth generation language (4GL) . 

a^te^^i? ^ a lar ^ e of important "nuts 

»q 1? v C ° n ?^ jj** 111 actually implementing a change in the 
dbSLrfU? L ^f** 1 ?" 2 16 Ve ^ ^Pcrtant long term institutional 
SorS^ ScSL. aFPllCatiQn "* inCreas ^ ^^tion of the 

The SUPRA/Svmmetry Package 

S^ri t0 n^ Y ' JS* CUnr S t a i* lication software vendor (SCI) and the 
current DBMS software vendor (CINOOM Systems) forged a joint program to 
™J * 1 ^ ge a °T a *^no«i relational DBMS and an Administrative 
inquiry' system designed to fit within and build upon the University's 
e3a f tl "I application software base and data files. University management 
reviewed t-is opportunity and was positive In its conclusion. 9 

f?5S* ¥L * K ^P^ 3 ^ 1)386 management system from CINCCM, had 
already been identified as one of the prime candidates for the next DBMS 
and had scored high in the selection criteria. SUPRA i<3 one of the 
leading advance technology DBMS's and comes with a fourth generation 
language (MANTIS) and an ad hoc query system (SPECTRA) . SUPRA passes data 
defined by external schemas or data '►views"; these data •►views" can be 

?<££?5* f ™ n 630 ? ^? user an ? have security to the record and 
element/field level. Since TOTAL .is also CINOOM' s product there is a high 
level of support for migration tools and conversion guidelines. Another 
plus for ST?'* was chat it was already installed in the local Hartford 
J* 6 * at c - commercial sites, in fact one of the companies had 

baen a - ' site for SUPRA. Discussions with local SUPRA u. «rs 
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Indicated that the product was very favorably regarded. It was stated 
that application programs need to have only non-logical changes done, 
since SUPRA supports the existing COBOL TOTAL statements. In summary, 
SUERA is a proven advanced DBMS that has a flexible migration path as well 
as a number of inplementation options. 

On the application side, the software vendor (SCI) offered an on-line 
A±irinistrative Inquiry System using MANTIS (the 4GL) , which utilizes the 
technology of SUTRA to acc3ss the production data on-line and produces 
management summary information. Our implementation would be the first in 
which the SCT products would operate with SUERA in an actual production 
environment. It was expected that there would be unknowns, but, with the 
experience of other sites and the tools available from CINOCM, unexpected 
problems to be encountered were judged to be a very low risk. Further 
more, in case of a catastrophic event, there were CINOCM utilities to 
return us to the original TOTAL environment. As the first site to use 
this project package, there would be significant vendor (SCT) support also 
provided* 

SUTOA/Symmetrv Project 

The accounts receivable (ARIS) , human resources (HRIS) , and student system 
(ISIS) were to be a part of the migration to the new environment, while 
the financial system (UTS) was deferred because it would require both an 
upgrade to the TOTAL version of the IFIS software as well as a migration 
to the new SUERA DEMS. This decision was based on the recent upgrade 
experience of the human resources system, the first estimate of the 
project requirements, and the resources available. Hie upgrade and 
migration of the financial system was positioned after the completion of 
the SUH^Symnratry project. 

The time frame for this project was to begin after the end of the spring 
term processing (end of May) and to accomplish practically all of the work 
before the fall registration period (late August) . 

Framework Planning 

Starting at a high level perspective, the project components were 
identified and then broken down into further details. Due to the 
uncertainty in a number of areas, flexibility in implementation was to be 
a keystone for achieving goals - a "framework" project plan. 

The major project corponents were specified and alternatives to achieve 
these components were laid cat. The testing and evaluation of the 
implementation alternatives were an integral part of the project. 
Decisions based on these evaluations and recomtnendations would ultimately 
deter m ine the final inplementation path for each major project component. 
This approach allowed progress both in the overall project and in the 
investigation of the inplementation details for the project. In a number 
of cases the work from one project component helped refine the 
alternatives in another component. 
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Our first iicportant task to be accomplished was the training, by CINCEM, 
of the professional staff - date base specialist, systems analysts, 
analyst/prograitners, and data security administrator. The data security 
administrator was to be the backup for the data base specialist and there 
were also a number of features of SUERA that touched upon the area of 
controlled access and security of the production data. 

Major Project Plannim Areas 
Staff Training 
Data base conversions 
Program conversions 

Production job conversions (JCL changes) 

Operational modes of SOTRA 

Management Summary Screens (Symmetry products) 

Computer Services staff training was a key task and was the first to be 
accccplished. Analysts and programmers were trained in Mantis, which is 
the new 4GL and the development language of SCT's Administrative Inquiry 
System (part of Symmetry). The data base specialist and data security 
administrator completed the recommended training in the technical aspects 
of SUPRA. 

Data Conversion Paths 

Early considerations as to which path to take for migrating the current 
data touched upon a number of issues, such as ease of acxraiplishment, 
assurance of success, and minimum resource requirements. Data conversion 
considered two aspects - physical data "structure" (or internal schema) 
and logical data "design" (or conceptual schema). For purposes of 
discussion in this paper, data "structure" is the physical placement and 
accessing of the data by the DBMS, while data "design" is the result of a 
data analysis and normalization process. Only the data "structure" was 
included in this project, since the data files already existed and the 
normalization process would be a major project itself. Most importantly, 
this normalization process did not have to be accomplished in order to 
achieve the project goals. 

Since the data was in the TOTAL data structure, there were CINOCM 
utilities provided to convert the data to the new SUH*A data structures, 
which I will describe as "converted" and "native". The "converted" 
structure was a quick, safe intermediate step, but did not provide the 
operational performance of the SUPRA native data structure. The path to 
SURRA "native" data structure would take much more time and would be more 
difficult to return to the TOTAL data structure in case of a major 
problem. Choosing the "converted" path meant that, for the short term, 
performance of all the data base application systems would be adversely 
affected and additional tuning would be required. 

Operational Options 

The HM 4381 ocnputer used solely for the administrative applications 
utilizing the MVS operating system and the on-line system software (CICS) 
presented certain operating limits for iirplementing SUH*A. It is not the 
purpose of this paper to go into technical details; however part of the 
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iitpleraentation plan did investigate and resolve these technical issues, 
The following brief discussion will, hopefully, clarify the issues and 
present the findings from the tests and the final conclusions, which were 
that SUHRA would operate within the existing computer resource limits and 
that the selected •'mode 11 of operating SUPRA for on-line applications would 
be different from the ••mode" selected for batch processing* 

Only two of the four operating modes for the physical data manager ("PEM") 
component of SUHRA were considered after initial investigations. One mode 
is called "central" where only one copy of the PEM is needed for a number 
of add r e ss spaces - in contrast with TOTAL vAiich requires a copy for each 
address space* On the other side was the "attached" mode where, like 
TOTAL, a copy resided in each address space* 

There was much concern about the CICS region address space requirements 
for all of the new SUIBA products (Data managers, Mantis, Spectra, other 
utilities) • The only way to increase the current address space limitation 
of 16 megabytes was to move to the MVS/XA option. This would have been a 
project itself and would have cause the postponement of the SUERA/Symmetry 
project. 

Experience at other installations and our in-house testing demonstrated 
that there was sufficient address space for all the software required. 
While "central" mode would require hitler operating system overheads for 
on-line processing, less address space would be needed for the SUPRA 
software packages. For production batch processing, where address space 
was less an issue, the "attached" mode would be used to achieve maximum 
performance. 

Program Conversions - Major Concern 

Conversion of existing production programs was considered to be the area 
of most concern, since hath changed programs and data would significantly 
increase the effort in testing and degugging. Although SUPRA was a tested 
product, this would be the first time that these production programs would 
be put into a real operational environment under SUPRA. Fran the 
perspective of the origin and language of the production programs, the 
following categories of programs were to be investigated and modified as 
necessary to achieve projects goals. 

Program Categories for Conversion 

Baseline Programs - COBOL vendor programs substantially unchanged from 
the vendor's original baseline (SCI) 

Modified Programs - COBOL vendor programs modified at the University 

University Programs - COBOL programs designed and programmed by the 
Uhiversity 

Other Programs - Non-COBOL programs written in other languages, such 
as Easytrieve and Socrates (an old CINOCM product) 




All of the programs used in the SCT integrated systems were written for 
TOTAL and the degree of conversion for running with SUERA was a major 
issue* To take advantage of the SUTRA technology for our objectives, only 
minimal revisions of the COBOL programs were required. Based on vendor 
information and our investigations, it was determined that about 11% of 
the approximate 1,100 programs in the program library needed minor 
changes* The non-OOBOL programs proved also to be relatively easy to 
convert; although the old CXNOCM report writei 'Socrates) programs proved 
to be a more of a problem and all of them were rewritten. 

Job Conversions - JCL Changes 

With utilities that were written in-house, the Job Control Language (JCL) 
statements were easily changed for all of the production batch jobs, 
although a few minor problems did crop up. An unexpected benefit was that 
the library space needed for the JCL decreased by a factor of 5, because 
the JCL information for the data base files now resided within the SUERA 
directory. 

The Unexpected - As Expected 

As expected there was the unexpected. Many of the unexpected events were 
positive. The installation of SUTRA and the Administrative Inquiry System 
went without major incident. Testing of the data conversion utilities and 
of the restoration of the old TOTAL data structure went relatively 
smoothly. Address space limitations were not a problem as first 
anticipated. 

There was a handful of exceptional program changes required to acccatimodate 
the different handling of certain functions and status codes between TOTAL 
and SUPRA. Sane examples are changing exclusive updates to shared 
updates, serial read of variable (related) file, and the status code 
returned with the "RENXT" (read next) command. 

SUPRA is a much more sophisticated DBMS and therefore is more 
complicated. Data integrity and schema architecture have many benefits; 
however they do require more resources and longer times in the 
implementation phase. Mthou^i the data base specialist had training as 
the first step of the project, the actual tasks he was performing were 
taking much more cxanputer processing times than anticipated. As a result, 
more judgement was required for assessing implementation alternatives and 
less canprehensive testing for every phase was possible in the project 
time frame. Each conbination of the alternatives for testing needed 
significant effort to finish the exploration and analysis. 



Independent Major Alternatives 

Data Structures - Five Data conversion utilities between the three 
data structures, (TOTAL, SURRA "converted" and "native") 



Appl icat ion Job Libraries - Batch and On-line applications for 
converted and original versions 



Data Bases - Two test data bases - "small" and production copy 

Modes of SUPRA operation - "central" and "attached" 

A judicious pruning of the alternative tree occurred based on vendor 
reoamendations, the experience of other sites, and most iirportantly our 
own grating experience. One of the conclusions was that the "converted" 
data path be selected due to time and risk considerations, although this 
would imply an initial lower performance level. 

Because of the significant lengthening of aoccraplishing data base tasks, 
it was evident that the DEMS tuning and population of secondary indices 
would also take longer than originally expected. However, iitplementation 
would occur after the busy periods in the academic calendar so as to allow 
time for the first round of tuning, which would achieve 80% of the desired 
results before the next busy period. 

Completed Project Baths and Experience 

Ihe actual project path was achieved on September 19, when SUPRA was moved 
into production. The data was converted to SUPRA "converted" data 
structure; the programs with TOTAL calls were changed where necessary and 
others rewritten; production jobs had the JCL changed for SUPRA; SUTRA was 
implemented in the "central" mode for on-line programs and in the 
"attached" mode for batch jobs. As a result of all the preliminary work 
and testing, the final tasks of moving to production and verification took 
13 hours. 

Ihe University's integrated systems have been operating with SUPRA since 
that time. Ihe move has been functionally "transparent" to the user, 
which, in this case, was very high praise for a job well done. 

Conclusion 

Ihe early planning recognized the uncertainties in the project and the 
benefits of making progress at the same time while evaluating 
iitplementation alternatives. Ihe University had a firm foundation of end 
user expertise, up-to-date computer resources, information system 
professionals, and a cxranitment to build upon the information systems 
investment it had made over the past few years. Key to this effort was 
the first completed task - training. Subsequent tasks used and built upon 
this base and the University's foundation in information systems 
experience, ihe "framework" plan worked well for this type of project in 
this institutional environment. if there been time to completely 
investigate the implementation alternatives, a different path may have 
been chosen that would have saved time in subsequent tuning and data 
conversion. The success of the project resulted in the University 
achieving another milestone along the strategic road to capitalize upon 
its investment in integrated systems. 
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Administrative Microcomputing 
Roads Traveled-Lessons Learned 

David L. Smallen 

Director, Information Technology Services and Institutional Research 

Hamilton College 
Clinton, NY 13323 



Abstract: Microcomputing, now a traditional part of the academic computing 
environment, can also be an important component of the provision of administrative 
computing services - but there are associated dangers. By following some simple 
strategies many of the benefits can be realized while minimizing the risks to the 
integrity of institutional information resources. Such has been the case at Hamilton 
College. The planning decisions that were made, results that were obtained, lessons 
that were learned, and disasters that were observed, are useful for other institutions 
considering desktop computing as an addition to the use of mainframe/mini based 
systems for administrative support. 
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The personal workstation, embraced as a productivity tool and heralded by some as the 
answer to the improvement of instruction, has had a harder time finding acceptance in 
administrative offices. Among the concerns about micros expressed by those responsible for 
managing administrative computing services arc: loss of data integrity resulting from offices 
maintaining their own data bases, and the loss of control over the selection of hardware and 
software with the resulting incompatibility of equipment and data. 

While not a replacement for centralized mini or mainframe based systems necessary for 
shared data bases, microcomputing can provide an important supplement to such resources, and 
help the institution make more effective use of its administrative computing dollars. Our 
experiences at one small college provide insight into the potential benefits, requirements, and 
liabilities of microcomputing. 

Historical Perspective 

Hamilton College is a private, coeducational, liberal arts college of 1600 students, located in 
upstate New York. While the institution has many traditions, going back to its chartering in 1812, 
its history with respect to administrative computing is relatively short Prior to 1974 all data 
processing was done on unit record equipment. The punched card was king and data redundancy 
the norm. The College acquired its first administrative computer in 1974, a 32K machine with 
10MB of removable disk storage, which provided batch processing for all major administrative 
offices until 1980 - a truly remarkable feat given the power of the systems that sit on desktops 
today! During this period the card was still at least a prince, but data redundancy was brought 
under control. 

In 1974, two critical decisions about computing spurred our use of micros. The first was 
our decision to use the Cornell mainframe (then an IBM 370/168) for large scale academic 
computing rather than purchase our own mini or mainframe. Not having to directly support such a 
system we were eventually able to devote most of our energies to integrating the microcomputer 
into our instructional program. Second, our computing services organization would serve both the 
•academic and administrative computing needs of the College, Thus support personnel developed 
expertise in the use of micros as soon as they were used in the classroom. Further, advice for 
hardware and software selection was provided by the same individuals. Table 1 indicates our 
current distribution of microcomputers in administrative offices. 



Table 1 

Microcomputers in Administrative Offices 



Office 



Number of PCs 



Office 



Number of PCs 



Academic Depts* 
Art Gallery 



11 
1 
1 
1 

2 
2 
3 
4 
2 
1 



Financial Aid 

Health Center 

HEOP Office 

Library 

Personnel 

President's Office 

Registrar 

Security Office 

Summer Programs 

VP Finance/Administration 



2 
1 
1 
6 
1 
3 
2 
1 
1 
1 



Bookstore 



Campus Center 
Business Office 
Career Center 



Computer Center 
Dean of the College 



Dean of Students 
Development 



*some offices serve several departments 



2 
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In 1980 Hamilton retired its original batch-oriented minicomputer system and obtained a 
multiprocessing system, with a view towards going "on-line". At just about the same time 
microcomputers had gained acceptance by the academic community, with the first applications 
being simple drill and practice, simulations, and word processing. Even the crudest of word 
processing systems on microcomputers showed great hope for addressing some of the basic needs 
of the faculty and administrative offices. But could they do more for administrative users? 

Some strategies 

While the initial foray into desktop computing was largely experimental and unplanned it 
soon became clear that managing the growth of administrative personal computers was necessary if 
chaos was to be avoided. Several strategies were devised to this end. In the remainder of this paper 
we describe the strategies and the results obtained. 

Standardize hardware and software configurations used in offices. 

Academic use of microcomputing necessitated a "controlled diversity" 1 of hardware and 
software, with hardware decisions driven by instructional software needs. This led to the support 
of three major operating systems MS-DOS, Apple DOS, and the Macintosh. We felt that it was 
important for data sharing and software support of administrative users that one hardware/software 
configuration be selected for administrative offices. The selection was based on two main criteria: 
availability of a variety of software packages for word processing, spreadsheets, and file 
manangement, and the existence of a file transfer and terminal emulation program that would work 
in concert with our on-line administrative computing system. Based on these criteria we selected 
the MS-DOS environment, as implemented on the IBM PC. 

We selected Multimate for word processing, Lotus 1-2-3 for spreadsheet applications, and 
PC-File/R for file management. The communications package we used was supplied by the vendor 
of our on-line administrative system software and features flow control for d?.ta transmission, and 
cursor control for terminal compatibility. Each of these packages was selected on the basis of the 
criteria of sufficiency to meet the needs of most of our users, and simplicity of use. Further, 
attention was paid to the ease of providing training and support for new users. 

The standard hardware configuration is a 640K machine with two floppy disk drives, serial 
and parallel ports. Users needing mass storage capabilities use the removable cartridge disk 
technology which provides a simple, and fast built-in backup system. One type of 24-pin matrix 
printer, one type of full character printer, and one type of laser printer are supported. This 
simplifies the problems associated with interfacing printers, hardware, and software. 

By selecting one hardware/software configuration we simplified hardware and software 
support activities. Training courses are run periodically for employees and employees trained in the 
use of the software can move from one office to another and immediately be productive. In 
addition, the body of trained users serve as an extended support organization - often users can find 
the answers to their problems by consulting other users. In addition, faculty that use the same 
hardware and software can exchange information readily with secretaries for document preparation. 
The existence of a "standard" configuration has encouraged some faculty to make purchase 
decisions for personal systems in ways that simplify their work. 

It should be pointed out that the most important aspect of the above strategy was the selection 
of one hardware and software configuration, not the particular choice of the representatives of that 
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selection. Since the selection period we have had reason to wish that we had originally made some 
different choices, but we have never regretted the fact that we standardized on one system for 
administrative use. 

Simplify the workstation operating environment 

Even in an environment of homogeneous hardware and software much can be done to 
simplify the operating environment of office employees. For example, we built a front-end menu 
for all users of workstations with hard disks (figure 1), In this way novice users are able to avoid 
the complexity of dealing with tree-structured directories that are necessary for organizing computer 
files efficiently. In addition, by maintaining a consistent approach to developing these menus we 
were able to easily modify them as users licensed additional software. 

Sample Menu 



1. 


Multimate Word Processing 


2. 


Lotus 1-2-3 


3. 


PC File III 


4. 


Connect with Cornell 


5. 


Connect with NCR 


6. 


Connect with Typesetter 


7. 


Thinktank 


9. 


Backup Bernoulli Cartridge 


0. 


Return to DOS 



Your Choice? 

Figure 1 

We make extensive use of batch files of operating system commands to minimize complexity 
for the user. For those users with the floppy-disk based systems we have utilized a start-up disk 
which contains all workstation configuration information (e.g. printer setup, file setup, 
clock/calendar access) as well as operating system software. Thus we avoid having to put this 
information on each software disk and simplify the process of making changes to the workstation 
environment. 
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Work diligently to avoid data redundancy 



The use of file management software can lead to the propagation of data redundancy as 
offices attempt to maintain information that is also part of the central data base. For example, an 
office might decide to maintain its own mailing list of employees. Since there is no direct 
connection between the two data bases, and each can change dynamically, the inevitable result is a 
duplication of effort and inaccurate information. How is this to be avoided? 

Education is the most important factor in avoiding data redundancy. Offices must understand 
that they have an interest in keeping the centrally shared data base accurate, and that information to 
be shared among offices must be maintained centrally. Office-specific information is appropriately 
maintained on the personal workstation. For example the following data bases are among those 
maintained on personal computers: parking fines and car registrations (in the security office), work 
orders (physical plant), computer equipment inventory (computer center), cable pair assignments 
(telecommunications), faculty publications (library), patient visits (health center). In each case the 
information in question is primarily of value to the office that maintains it. That office might shar; 
information with others through reports, but other offices do not need direct access to that 
information. 

Even in the above examples data bases often contain components of information that are 
available centrally. How is the office to avoid rekeying that information? We make use of the 
ability to download information from the central system to the office data base. For example, the 
auto registration data base must contain the name, ID, residence and class year of each student. 
This information is downloaded to the data base at the start of the academic year. Then the 
information about auto registrations, including the assigned decal number, is added to this base of 
information to provide the necessary data base used in assessing fines for illegally parked cars. 
Periodically, the security office can provide a list to the billing office of those individuals that are to 
be billed for fines. The listing contains the ID numbers of the offenders, eliminating the need for 
the information to be further modified for billing purposes. 

Avoid programming applications on personal workstations 

We have selected software that does not require users to write programs to accomplish work 
on personal computers. For example, we chose a file management program that does not require 
any user programming to maintain simple data bases. 

The main problem with user-developed software is the increased potential for undocumented 
and unsupportable administrative applications. Such applications, if they are important to the 
operation of an office, introduce a hidden liability to the administrative operation of the institution. 
Changes in personnel can mean a crisis situation. 

However, ihe situaton would be different if the central computer services organization can 
provide the programming services and support. Under these conditions the personal workstation 
becomes merely an extension of central computing services. This was not the case at Hamilton, so 
we tried to avoid such applications. 



Some successes 



What has been our actual experience with the above strategies in a small college 
environment? First some modest successes. 

The Personnel Data Base 



The College has a Personnel Office that is responsible for most aspects of employee 
relations, including benefits administration, and position management. While our payroll system 
efficiently processes the financial aspects of the payroll, it is a batch-oriented system that was 
designed for a different era. It contains a personnel biographical component, and information for 
any employee can be looked up on-line, but it lacks the flexible reporting capability necessary for 
our Personnnel Office. For some time we have considered implementing a new payroll/personnel 
system that would provide this flexibility, as well as additional information management 
capabilities. 

As an interim step we designed a system that was based on PC-File/R. Periodically, usually 
about four times each year, we download information from our central system to create a personnel 
data base. Once the information is under control of the file management software, the Director can 
produce the reports she requires. The system has been successful enough that we have postponed 
our consideration of a new centralized system for the last three years. Each time we raise the issue, 
the Director indicates that she does not see a substantial benefit to the new system over the approach 
she currently uses. 

Health Center Patient Visits 



Our Health Center handles over 9,000 patient visits each year. In order to plan for the 
provision of services it is necessary for the Center to be able to collect data on the type of services it 
provides, in particular, the number of individuals treated for various illnesses and the personnel 
providing treatment. We developed a PC-File/R application that allows this information to be 
entered on a daily basis. The Health Center has access to this information at all times in electronic 
form. In addition, an extract file is created at the end of each month that is transmitted to Cornell's 
mainframe for statistical analysis. The combination of a PC based application and the monthly 
statistical analysis provides important information for planning and management of the Center. 

Application Packages 

Our Campus Center has licensed a software package designed for the room reservations and 
other aspects of the Center management. The system was designed by a campus center manager at 
another institution and is now marketed nationally. It is well documented, support is provided by 
the vendor, and it operates on our standard hardware configuration. 

The acquisition of such software is a wise use of funds. Our computer center personnel 
support the hardware, and other software used on the system, and assist in implementing updates 
provided by the vendor. The Campus Center was thus able to acquire an application package that 
we did not have h*\d the time to develop in-house. 
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Some modest disasters 



All things do not work out the way they were planned. Some disasters were also observed 
during the last several years. Doug Van Houweling's principle that "it is not a bad thing to have a 
small disaster in progress at all times" 2 is one worth remembering when implemening any strategy. 

Incompatible environments 

In spite of the best of intentions incompatible equipment sometimes arrives on campus. Our 
most notable instance occurred when the chair of an academic department decided that the 
departmental secretary should have the same kind of microcomputer he used at home. He was able 
to circumvent the purchasing process and the equipment arrived on campus and was used. The 
secretary who used the equipment was not able to exchange information with other offices on 
campus and numerous annoying incidents occurred over the next three years, finally culminating 
in the replacement of that machine and the conversion of all documents to the standard software (at 
the expense of hiring a person for an entire summer). The original equipment now sits idle, with 
only one person at the College knowing how to use it. 

Not all incompatibilities in administrative offices arise from deception. Some are the natural 
result of the need to serve academic departments that use other hardware in connection with the 
instructional program. Thus we have several academic departmental offices whose 
hardware/software is other than our standard configuration. In these cases we have developed 
limited file transfer capability between the machines being supported on campus. The situation is 
not ideal, but necessary. 

The user who knew too much 

We had one situation in which a user who had learned some programming decided that he 
uould develop a system for his office. The project required that numerous Basic programs be 
written. We approached this project with great caution. On one hand we did not have the 
expertise to develop the applications ourselves on the PC, nor the time to program them on the 
central system. The application certainly seemed do-able on a PC but we had concerns about the 
quality of the programming, documentation, and office procedures that would result. The system 
would replace the data input from our physical plant for our weekly payroll, so there were 
potentially significant benefits, but also significant risks. We finally agreed to allow the project to 
go forward as an "experiment" and had the developer incorporate our file manager into the project 
to eliminate some of the programming. The programming was "finished" over the course of the 
next year. 

The system was useful for the office involved. Office personnel were able to more 
effectively manage the activities that the system was designed to handle even though there were 
numerous times when programs had bugs that created small crises. The developer soon moved to 
another office and did not want to continue to maintain the system, and the documentation was 
non-existent. This resulted in about nine months of difficulty as computer center personnel 
managed the small crises that resulted. Finally, we spent an entire summer rewriting, and 
documenting the system, to enable it to be maintained for the future. The resulting system has now 
worked without a failure for the last 15 months, and continues to serve the needs of the office. The 
main problem with the current system is that we do not have the time or expertise to modify the 
system to incorporate new features desired by the office. 



Lessons learned 



Many lessons were learned over the last five years. We mention some of these briefly. Each 
of these has implications for the organization responsible for providing computer services. 

1. Avoid the "let the student worker do it" syndrome* Administrative offices often use 
students to "do the work". This results in the development of student expertise but not expertise 
of the employees of the office. Using students in this way is often the easy way out, since many 
of them do not need extensive training. Of course this is short-sighted on the part of the office 
manager, and can lead to crises when the student worker returns to the role of student. This is 
often compounded by not providing the time for office staff to attend computer training courses. 
The result is that hidden liabilities are introduced into the office operations. 

2. It takes, on average, one disaster before even the most conscientious user will 
regularly back up data files. Despite incorporating horror stories into each computer 
training course we find that even the most cautious of users requires a "personal experience" 
with losing data files before the concept of backup becomes internalized. A sign that has 
become popular on campus states "Blessed are the pessimists, for they have made backups". 
Backup must be continually emphasized and simplified. In addition, computer services 
personnel should develop experience with the use of "fi ! e recovery" utilities. 

3. Microcomputer support needs are underestimated, sometimes dramatically. Some 
notable examples include the time it takes to update 35 copies of a word processing package to 
the latest release; the tine it takes to teach users the new features of the upgraded package, and 
the time spent with the users who cannot attend the training sessions. Standardization does not 
eliminate the need for support it only makes it manageable. The obvious implication is t" iat 
staffing needs will be greater than anticipated. 

4. Users 1 perspective on time changes as they become proficient. Users forget how 

long it took to find something that was in a folder in a filing cabinet. They are impatient if it 
takes more than 30 seconds to locate the same information in a data base containing several 
thousand records. Remember how long it took to get all the materials together for something 
you were typing? Now users are impatient if it takes more than 10 seconds to load the 
document that they were working on when they last left the machine. This will be a factor 
driving people to faster machines and disk technology. Awareness of this phenomenon is 
important to help users make sensible hardware choices. 

5. The availability of support services encourages standardization* This is a variant 

of the "carrot - stick principle". Most, but not all, users will see the value in using a system that 
is being used widely on campus. This is the most important reason that standardization 
simplifies support needs. It should be pointed out that standardization can be more expensive. 
For example, the standard package may be more expensive than others that do basically the 
same task. In spite of this, users are usually willing to make the trade off of the cost of a 
product for the availability of support. The computer services organization must continually 
emphasize the value of support. 

6. Users must become more independent if support costs are to be managable. 

Inherent in distributing the computing power through the use of micros is the need for office 
personnel to become knowledgable users. As Phyllis Sholtys has said in discussing the role of 
the office micro user, "There is, however, increased responsibility that accompanies such 
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increased freedom and flexibility", 3 This does not mean office personnel must become 
computer experts, but rather intelligent managers of their office computer environment Users 
learn much from each other, and they must learn to accept a greater decree of responsibility for 
their computing than would be the case in a centralized computing environment The computer 
services organization must remind itself that they should teach users how 10 do things for 
themselves rather than doing things for them, 

7. Printers will be a major source of problems. Despite a reasonable level of 
standardization the most technical part of using a software package is understanding how to 
make the printer do what it should. Hardware reliability is necessary but not sufficient to avoid 
problems, A large portion of user problems result from not understanding how the printer can 
be controlled within a software application, 

A mundane but important point that is often overlooked in planning for the office workstation i 
that sound enclosures are needed for all but the most casually used (or expensive - laser) 
printers. Failure to recognize this results in a disruption of office operations, 

8, Users will be creative and inefficient. Computer professionals and naive users don't 

use computers in the same way. It is common for a user to discover a way "that works" and to 
continue to use that method even if that is not the "best" way to accomplish that task. An 
example is the confusion between the use of spreadsheets and file managers. The similarity 
between the use these two applications for keeping track of information often means that users 
make the wrong choice, using the software with which they are familiar, rather than Ihe one best 
suited to the task. 

It is incorrect to assume that because users don't ask questions that they understand what they 
are doing, A valuable support technique is "support by walking around" to offices and 
watching what people are doing. It is imjx)rtant in this regard to avoid teaching novice users 
short-cuts, the use of these "time-savers" invariably will result in an increase in support 
questions, 

9, Training is a continual support need. Even with standardization of the workstation 
environment changes in personnel, upgrades to hardware and software, and the availability of 
new capabi ?: ties necessitates a long term approach to providing computer support. Despite the 
distributed nature of the equipment, the need for a strong centralized support organization, one 
that can coordinate training and other support functions is essential. While knowledgable users 
become an extension of centralized support, their jobs do not depend upon providing computer 
services. There must be an organization whose responsibility is to coordinate both the 
centralized and decentralized administrative computer services, A variety of training methods 
should be available (e,g,, audio tapes, short courses, weekly meetings, hands-on seminars), 

10. Office managers should take a leadership role in implementing technology in 
administrative offices. The office manager must understand how the technology is being 
used, its limitations, the training needs, and the possible benefits and risks of the applications 
being used. Without the involvement of the office head the potential benefits of the technology 
will not be fully realized. 

h\ our experience, it has been all too common for the office manager to be a non-user of 
computer technology. In such cases the office personnel fail to utilize the equipment in the most 
effective manner to meet the office's information needs. Worse yet, important decisions about 
the information management needs of the office may be delegated, de-facto, to clerical 
personnel. 
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1 1. Legal and ethical use of software must be encouraged. Software copyright laws are 
not easy to understand, and much incorrect information exists about what is permissible. We 
have had to continually remind office personnel of their obligations with respect to the proper 
use of the software that the College has licensed. In this regard it is important that policies for 
software use be developed campus- wide. We have adopted a policy on software use and have 
distributed the brochure "Using Software 11 ^ to all employees of the College. The computer 
services organization must encourage users to act responsibly. 

Recommendations and Conclusions 

In order to implement some of the above strategies it is necessary that high level 
administrative support be evident for them. This requires that a procedure be in place so that 
requests for microcomputer equipment can be reviewed for consistency with institutional strategies. 
It must be recognized that this approach will often appear to be more costly, and bureaucratic, but 
in fact will be more economical when personnel and training costs are considered. 

It is inevitable that microcomputers will find their way into administrative offices by the 
nature of their use in support of the teaching and research needs of the college community. What is 
important is the way in which their use is managed by those responsible for providing 
administrative computing services. The application of microcomputer technology in such offices 
has many potential benefits, and associated dangers. By following some simple strategies many of 
the benefits can be realized while minimizing risks to the integrity of institutional information 
resources. 
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MURPHY'S 1ST LAW AND ITS APPLICATION 
TO ADMINISTRATIVE COMPUTING 

Mary Lawarre Cox 
William E. Updegraff 
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Springfield 
Ohio 



Murphy's 1st law is well known. Its application 
during the administrative computing conversions at 
Wittenberg University from DEC/ Quodata/ QDMS/ Archon 
systems to PRIME/ DATATEL/ INFORMATION/ Colleague 
systems is chronicled for the unsuspecting and 
unknowledgeable . 

This particular form of Murphy's 1st law is the 
Gestalt form;, i.e. when anything can go wrong in an 
integrated environment, it will do so exponentially. 

CAUSE members should not be surprised to learn that 
Murphy's 1st Law was well demonstrated at Wittenberg. 
Its pervasiveness is documented in this paper. 
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I. INTRODUCTION (Murphy's 1st Law, Corollary I - You will 
be lulled into a sense of complacency prior to 
utter chaos. 



In the early to mid 1980 's, Wittenberg University 
operated its administrative computing functions in what we 
believe was an extremely effective fashion* Effective 
because all administrative systems were fully integrated 
under a common linked-file data management system, QDMS from 
Quodata Corporation. All administrative functions were 
computerized under QDMS; 70% were in-house systems and 30% 
were purchased. The database permitted production of ad-hoc 
reports within systems and linked ad-hoc reports across 
systems without any programming whatsoever. These reports 
could be formatted automatically or precisely formatted with 
a user defined page layout. A full-time administrative 
computing staff of three including one operator/programmer 
served a user community of 2,346 (2,214 FTE) students, 141 
faculty, and 300 clerical and professional staff. 

As we learned to use the QDMS resources effectively, we 
also became constrained due to our Digital Equipment 
Corporation (DEC) PDP 11/70 memory, architecture, and 
performance limitations. Within the limits of our hardware 
and software, we felt we were on the cutting edge. When we 
reached the point where we could not make or expect 
significant improvements, we conveyed our concern to the 
Executive Committee and President and projected replacement 
of the hardware and software in a progression of 5-year 
plans. Although funds were not available, we tried to stay 
abreast of the marketplace just in case. 

In the fall of 1985, a series of highly unusual events 
occurred. First a substantial unrestricted bequest was 
received by the University. Second, several major offices 
including Admissions and Advancement had encountered the 
limitations of our QDMS/PDP 11/70 software/hardware 
combination and were actively pressing for replacement. 
Third, and perhaps most importantly, our President was 
prepared to support funding administrative computing within 
his round-robin method of dealing with major University 
capital funds needs. 

The preceding optimal circumstances were not known to the 
Center staff in October 1985. We were "lulled into a sense 
of complacency and well being." 
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II. SELECTION PROCESS (Murphy's 1st Law, Corollary II - The 
better prepared you believe you are, the more likely the 
resulting chaos . ) 

A. Driving Criteria and Considerations 

In October 1985 with no preamble, the Center was 
requested to prepare a plan for selecting new 
administrative computing software and hardware. On 
November 1, 1985, we suggested five options and a five 
month assessment period. The five alternatives were: 



1. Britton Lee/DEC 

2. Information Associates /DEC 

3. Datatel/PRIME 

4. CARS Information Systems Corporation/DEC 

5. Quodata Corporation/DEC 

These five alternatives were analyzed by Center staff 
on the basis of the following four criteria. 



C-l. The procurement would be software driven, rather 
than hardware driven. 

C-2. The software was required to be based on a 
relational or a "near-relational" type of data-base that 
had a sufficiently flexible report writer to permit end 
users to produce creative linked reports without 
assistance of Center staff. 

C-3. The software was required to possess a full 
spectrum of administrative computing applications so that 
development of in-house applications could be minimized 
or eliminated. 

C-4. The thrust of the application software was 
required to support decentralized computing with user 
offices controlling their own destinies as much as 
possible. 

Within one week of our initial proposal, we were 
requested to narrow the five alternatives to two and cut 
the evaluation period to two months. 



B* Evaluation Process /Departmental Involvement 

In addition to the evaluation criteria by the Center 
staff, statements of needs were developed at University- 
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wide and departmental levels ♦ These needs were used as 
final evaluation criteria. The final twc vendors were 
then requested to make extensive on-campus presentations 
to the user departments of the University. The vendor 
documentation, vendor demonstrations, and information 
learned from existing vendor customers were used for the 
final analysis and selection. It had been hoped to make 
one week visits to existing user sites of the final 
alternatives but time and circumstances did not permit. 

Dr. William Kinnison, Wittenberg's President, was 
astute in requiring executive level approval of the final 
decision. While the Center staff assisted in the initial 
culling, the final choice was made by the users through 
their representation on the Executive Committee. Hence, 
the "ownership" of the hardware and software resides with 
the user departments, not the Center. This was a 
fundamental departure from previous procurements of the 
University and fully in step with evaluation criteria C-4 
dealing with decentralized computing. 

C. Resulting Selection 

The final decision was delayed until March 1986. 
Suffice it to say that a comprehensive contract was 
signed with Datatel Corporation for both the software and 
hardware. It is beyond the scope of this paper to 
discuss the analysis leading to our decision. 

The whole evaluation and selection process was 
chaotic in spite of the continual assessment and study 
over the years that had preceded the procurement. Hence, 
Corollary II of Murphy's 1st Law, "The better prepared 
you are, the more likely the resulting chaos." 



III. TRANSITION CONSIDERATIONS (Murphy's 1st Law, Corollary 
III - It will always be worse than anticipated.) 

A. Special Problems in Converting from One Fully- 
Integrated System to Another Fully- Integrated 
System 

We believe that Wittenberg's conversion efforts are 
unique in that the University already was using fully- 
integrated systems linked together by Quodata's QDMS 
software. This high level of integration has made the. 
transition to Datatel' s fully-integrated systems very 
difficult. Initially, we considered cutting over the 
whole University with a week's time, essentially shutting 
down during that period. However, we determined that we 
didn't have sufficient support staff. Since we had to go 
piecemeal, work-arounds on both the QDMS and Datatel 
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systems were developed to simulate the integration. The 
ordering and timing of conversions likewise has been very 
critical. 



B. Physical Connection of Terminals and Devices - 
Local Area Network 

During conversion, users needed to have terminal and 
microcomputer access to both the DEC PDP 11/70 and PRIME 
9955 Model II computers. This problem was resolved by 
extending the University's VAX-based XYPLEX local area 
network to both computers. Consequently, users can issue 
"connect" commands to whichever computer is appropriate 
during the conversion process. 



C Scheduling (Initial) 

Development of the initial schedule for training, 
conversion and network installation was carried out in 
consultation with Datatel staff and projected an 18 month 
period. This schedule was developed as a best guess 
three months before the hardware ever arrived. Within a 
few months of hardware/software installation, Center 
staff realized that at least 2 1/2 years efforts would be 
required. Meanwhile the Executive Committee was 
pressuring to reduce the schedule to 12 months. The 250% 
difference in expectations was potentially disastrous. 
More will be said later in Section IV. 

Hence, the statement of Murphy's 1st Law, Corollary 
III "It will always be worse than anticipated" is 
appropriate. 



IV. AGONY OR "THE NITTY-GRITTY UNEXPECTED PROBLEMS" 

(Murphy's 1st Law, Corollary IV - When things seem 
t o be at their worst , they're not, or it's always 
darkest before it's pitch black.) 

A. DEC to PRIME Transition Problems 

The PRIME 9955 II computer hardware was installed in 
mid-June 1986, one month later than anticipated. Datatel 
Software was subsequently installed in mid-July 1986. 
Initially, we experienced a number of problems due to a 
lack of familiarity with PRIME hardware and the PRIMOS 
operating system. We had been assured by PRIME and 
Datatel that there would be "no problem" with providing 
DEC VT-100 terminal capability which was critical because 
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most of our video terminals were DEC VT-100 compatible 
While the implementation of VT-100 capability is 
straightforward in principle, we were one of the first 
Colleague user institutions to migrate from DEC to PRIME 
and one of the first institutions to install DEC VT-100 
driver interfaces. 

A second problem was incompatibility of DEC and PRIME 
tape utilities. We ended up using custom programs to 
avoid difficulties. 

A third major factor when changing hardware vendors 
is the loss of staff expertise and the time required to 
bring existing staff back to expertise levels held on 
former hardware. 

B. PRIME INFORMATION Considerations 

The PRIME INFORMATION database which underlies 
Datatel's software is absolutely superb. However, the 
database lacks a major feature which has made conversion 
much more difficult for us: the lack of a formatted or 
page style report writer. (This should not be confused 
with the single line per transaction type report writer 
which is present and is excellent!) Currently custom 
programming is required to produce paragraph or page type 
reports (e.g. class rosters, phonathon cards, student 
invoices). While the technique is relatively straight 
forward for programmers, it is beyond the capabilities of 
end users. Since two of the objectives of our 
procurement were to minimize program maintenance and to 
place a powerful ad-hoc paragraph-style report writer 
directly in the hands of our end users, we have been verv 
disappointed. 

Offsetting this disappointment was the "Pick" type 
power of PRIME INFORMATION. We now had variable length 
fields, multiple-valued fields, and unlimited- length 
records with the capability of storing lengthy comments. 

C Conversion Calendar Catastrophe 

The other problems contributing to conversion were: 

!• The lack of a common definition of "conversion" 
between Wittenberg and Datatel. Datatel's definition 
was essentially a simple translation of previous data, 
training on the new software, and cutover. Wittenberg's 
understanding was different - Wittenberg had the need to 
reproduce existing functionality without major concern 
for esthetics. This meant possibly adding bells and 
whistles to the product if the bell was already being 
rung by an end-user. 
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2. Scheduling underestimates. Wittenberg had only one 
other conversion in its administrative computing 
history. When Datatel originally suggested 12 to 18 
months as being sufficient, we were not in a position to 
contradict. 

3. Staffing Level Problems. Two types of staffing 
problems occurred. The first was failure of the 
University to provide a temporary programmer as proposed 
from the inception of the project. The second problem 
was the unsuccessful attempt to directly involve all 
Center staff in the conversion effort. For reasons of 
better morale, our initial conversion efforts had 
involved all Center staff. Unfortunately, we could not 
find adequate time to dedicate to conversion in this mode 
while continuing to maintain the old systems. 

4. Inexperience. Conversion is a unique experience. 
Since conversion is likely to occur only once every five 
to ten years, conversion was completely new to most of 
our staff. 

5. Inability to Identify Similar Conversion Efforts. 

We made very conscientious efforts to contact a sizeable 
number of institutions about potential problems that 
might occur during implementation and conversion. 
Because of our existing level of development, the 
information gleaned from representatives from most other 
institutions did not reveal the scope of the necessary 
conversion efforts. 

By December 1986, we had reached the state that we 
ascribe to Murphy's 1st Law, Corollary IV. "When things, 
seem at their worst, they're not or it's always darkest' 
before it's pitch black." 



V. PRACTICAL SOLUTIONS. (Murphy's 1st Law, Corollary V - 
The more work you do, the more there is to be done.) 

A. Picking Up the Pieces 

By Fall 1986, Center staff realized that an 18 month 
conversion schedule was impossible. The Provost was 
apprised of the situation and informed that a three-year 
schedule was appropriate to complete a high quality job. 

Because of legitimate doubts, the Provost sought and 
received high level consultation with Datatel to 
recommend a new schedule and to identify additional 
resources necessary to successfully complete the 
conversion. This move was astute and ultimately gave 
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credence to the Center's estimate of a three-year 
schedule. Besides seeking assistance from Datatel to 
help develop the revised schedule itself, the University 
contracted with Datatel for extended services support to 
provide management assistance, on-site training, and off- 
site programming support during conversion* 

As part of the solution, major changes were made in 
Center staffing patterns* First, the conversion efforts 
were almost completely separated from the maintenance 
efforts* We hired one temporary programmer and 
reassigned a staff member from systems /network activities 
to the administrative conversion team* Our staff of 
three grew to five. Three people were assigned full time 
to conversion and two people to supporting the existing 
systems. 

The Executive Committee of the University decreed 
that enhancements by Wittenberg Center staff beyond the 
functionality already present in the QDMS systems would 
not be attempted as part of conversion. This lowering of 
internal expectations in user offices has been a critical 
factor in the successful maintenance of the new three- 
year schedule. 

Once all of these arrangements were made and 
implemented, the conversion tasks became possible, albeit 
extremely demanding and exhausting. 

A typical pattern has evolved in all of our 
conversion efforts: 

1. Users are provided with initial documentation about 
their new system and given access to a trial version of 
their new software. 

2. Center staff study and investigate software, trying 
to identify relationships between old and new files and 
fields. 

3. Initial training is carried out by Datatel staff at 
Wittenberg for Center staff and users. 

4. Soon thereafter a Datatel representative and 
Wittenberg staff map old fields and files to Datatel 
fields and files. 

5. Final mapping specifications are sent to Datatel for 
programming. 

6. Users continue to investigate systems and enter code 
file information in the trial account. 

7. After initial version of the conversion program is 
received from Datatel, Wittenberg staff make corrections 
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aivi modifications* Data integrity is carefully checked 
by Wittenberg staff* 

8. Functions and reports not supplied by the "canned" 
software are put in place. 

9. Full conversion is carried out in the test area 
first. Back and forward links between old and new 
systems are developed. 

10. Conversion is carried out and cutover is made. 

11. Cutover problems are resolved. (So far such problems 
have been minimal and satisfaction high.) 



B. Successes! 

Full conversions have been completed for Advancement 
and the Business Office (General Ledger, Accounts Payable 
and Accounts Receivable). In addition, the Cashier's 
Office and Purchasing Office have been brought on-line. 

C. Future Conversions and Schedule 

By the first of the year', we will be live with 
Payroll and Personnel. Admissions and Financial Aid will 
be cut/over by the end of January 1988. 

Currently, we are planning conversion of Registrars 
systems in the spring. All basic systems will be 
completed by July 1988. The last year of our efforts 
will be dedicated to secondary applications already 
developed on the old system; e.g. Career Development, Car 
Registration and Inventory. 

It becomes clear that Murphy's 1st Law, Corollary 5 
holds: the more we do the more we have to do. 



VI. CONCLUSIONS (Murphy's 1st Law Continues but it's 
still possible to laugh.) 

We have proceeded from euphoria (the selection and 
purchase of new software) to despair (realization that 
our calendar was unrealistic and staff support 
inadequate) to cautious optimism concurrent with 
continual exhaustion. We are confident that 7/e are 
proceeding in a realistic and attainable schedule so long 
as our health and morale can be maintained. 

We have general advice for other institutions 
considering switching to new state-of-the-art software 
and hardware. 

- 8 - 



9 

ERIC 



36 



Do not underestimate the length of time required for 
conversion or the additional staff required during the 
conversion process . One suggestion is to byte the bullet 
by hiring an external consulting firm to estimate the 
scope of the conversion tasks, the length of time 
required, and the staff and financial resources 
required. We did not do this and made a tactical mistake 
in not so doing* The analysis permits uniform and 
realistic expectations to be formed by everyone from data- 
entry clerks to the president. We could have avoided all 
the "prophet in one's country" syndrome* 

We also recommend that an institution separate its 
staff resources into a sub-staff responsible for 
maintaining existing systems and sub-staff responsible 
for converting/implementing the new system. Existing 
staff will not be enough* We can assert that temporary 
staff must be employed. 

There are a number of excellent and continually 
improving packages available. No canned system can 
supply all of the functionality to satisfy an institution 
which aspires to excellence and wants to stay at the 
cutting edge. Therefore, when shopping for 
administrative software, you've only done half the job 
when you determine that a vendor's software functionality 
meets your basic needs. The power of the data base 
underlying the vendor's products must be examined just as 
closely. If maintenance of the administrative systems is 
with an outside vendor and powerful tools are available 
within the data base, then it only requires a small 
energetic creative staff to take any college or 
university to the forefront. 

Finally, we want to make a public statement in 
support of both Quodata Corporation and Datatel, Inc. as 
vendors of high quality administrative computing 
software. Our decision to switch to Datatel was complex 
but bas^d heavily on the lack of available developed QDMS 
administrative applications on VAX systems at the time of 
our procurement. Quodata Corporation has very 
competitive systems and should be seriously considered as 
a vendor. The Datatel packages that have been converted 
are working well with performance more than meeting our 
expectations. The ease of use of the PRIME INFORMATION 
query language INFORM has been an absolute joy for our 
end users. In our estimation, the Pick operating system 
of which PRIME INFORMATION is a variant is one of the 
most powerful and elegant data bases in existence. It 
has to be experienced to be appreciated. 

We still have much work ahead for the next 12 to 18 
months. We still have difficulties but much of the pain 
is behind us. Throughout the process, we have managed to 
keep our sanity by laughing at ourselves. In spite of 
Murphy's 1st Law, we still survive! 
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Abstract 

Many higher education institutions as well as software vendors who provide applications 
software to institutions have attempted to move gradually from conventional file 
structures and access methods to the technology of data base management system. 
There have been and are significant impediments to this transition. For the institution a 
double barreled drawback exists of massive conversion and a staff who for the most 
part are untrained in and inexperienced with the DBMS technology. The software 
vendor seems further impeded by the realities of the third generation marketplace. 
Carnegie Mellon University has chosen to leverage its significant technological expertise 
with DBMS (particuarly relational) into joint technological and developmental 
partnerships with a few DBMS and application software vendors. These partnerships 
have and will result in a base of knowledge in support of the transition to relational data 
base technology. 
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Computing Intensive 

Carnegie Mellon University located In Pittsburgh, Pennsylvania Is the home of a College of Fine 
Arts, a College of Humanities and Social Sciences, the Mellon College of Science, the Carnegie Institute 
of Technology, a School of Urban and Public Affairs and the Graduate School of Industrial 
Administration. It not only offers a computer Intensive environment to its 6500 students, 400 faculty 
and 1900 staff but also serves as an intellectual resource for the 1.1 million residents of the Greater 
Pittsburgh area. 

Carnegie Mellon Is also home of nearly 4000 University owned computers. These include one 
IBM 3083, more than 100 IBM PC-RTS. In excess of 2000 IBM AT, XT, and PC class computers; 
slightly under 100 DEC VAX 8650, 8700, 8800, 11-780, and 11-750 machines; 5-10 DEC 2060s, 
more than 500 Microvaxes, approximately 200 Sun II and lil workstations and in excess of 100 Apple 
Macintoshes, MAC-SE's and IPs. In addition to university owned computers, more than thirty percent 
(30%) of the student body own their own computers and over forty percent (40%) of the faculty own 
their own computers. 300-400 computer professionals are employed on campus, many of whom 
directly support various academic and administrative functions. 

Intellectually Inspired 

Speaking to new faculty in August of 1987, Dr. Herbert Simon, University Professor of 
Psychology and Nobel laureate provided an intellectual perspective of Carnegie Mellon when he told the 
faculty about the computer intensive environment. He said: 

n You are all aware that CMU Is pioneering In the domain of networked communication as a tool of 
education. There Is an Important distinction to be kept in mind here. We do not think of CMU as a 
computerized campus - though you will see many computers here. I want you simply to understand 
that the computer network has been built here as an experiment, an experiment in education in which 
we are ail participating. Neither the Administration, nor the Faculty nor the proponents or designers oi 
the system have more than a hazy idea of what its rote will be ten years from now at CMU (if we 
haven't meanwhile torn it out). And its role will be exactly what you make it, or choose not to make it, 
through your Ideas of how it can enhance your teaching and your research. It is an invitation to be 
innovative. " 

Carnegie Melton's innovative and creative spirit permeates many areas of the University. It 
is this spirit of innovation coupled with the opportunity to experiment with new ways of thinking about 
solutions to problems that has given rise to the notion of technology partnerships in administrative 
computing and information systems. The idea is also born from a neod. The need exists to provide 
better information to meet the ever present demands of a changing enterprise. As Dr. Simon so aptly 
pointed out, *Carneg»3 Mellon will change in ways not yet imagined.- Colleges and universities should 
use information and the software that drives the production of information as strategic tools of the 
enterprise with the flexibility to be moved from one operating system environment to another. The 
portability of software permits the University to take advantage of opportunities offered by the 
changing technologies. In a Carnegie Mellon University report dated September, 1987 the commission 
to evaluate the President cited Information as one of four primary resources that the President must 
gather and allocate. Further, the Commission suggested that as an administrator, 'the President must 
govern managerial information. 11 

Administrative Information Systems Environment 

The university President and others who govern and administer Carnegie Mellon recognize the 
importance of flexible and powerful information systems which will enhance administrative processes 
and provide information as a resource to a broad base of constituents. Executives, administrators, 
deans, department heads, middle managers, staff and faculty are among the traditional consumers of 
Information to which will now be added students, parents and guardians, corporations, foundations and 
alumni a? well as governmental and legislative bodies. 

The recognition of (information) need across a broad spectrum of constituents has led CMU to 
explore joint efforts with a few commercial firms so as to: (1) develop software which will provide 
needed Information, support new strategic functions and enhance existing administrative functions and 
(2) multiply the effect of the University's available resources. 
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Administrative System applications can be found running in somewhat peaceful coexistence on two 
DEO 2060's; a DEC VAX b700; three VAXH-780's; an IBM 3083 EX, a 3Com Based, K3 Ethernet 
LAN; several Appletelk networks as well as stand alone personal computers. The current direction Is 
to migrate strategic administrative applications from the IBM 3083 and the DEC 2C60's to an 
integrated, relational database environment operating on a cluster of two DEC VAX 8700's (running 
VMS) December 1989. 

The strategic intent is to utilize state of the art relational data base technology and create 
advanced systems functionality. For the next few years the administrative information system 
services, support and development at CMU will be centrally planned, managed and implemented 
Planning and oversight of implementation by non-central departments will improve the probability 
success. Recent efforts to design and develop a university information system (UIS) data base and to 
define the functions and features of student and human resource information systems have psovided a 
model for collective participation, planning and oversight by many university constituents. 

The result of the next implementation of administrative information systems will not only 
provide for distribution of processing and computing, but also provide a basis for distributed data 
bases. While some enterprises and only a few Universities moved to data base applications in the late 
60's and early to mid-70's, Carnegie Mellon developed applications where programs and data were 
inextricably intertwined, file and data structures were relatively straightforward. We initially were 
concerned about relational data bases used in intense transaction-oriented applications. The rapidly 
decreasing price-performance ratio of processors channels and disk storage, however, caused this 
relative inefficiency to be less of a concern to the CMU information systems planners. Further, the 
portability of application code and the development productivity are key strategic issues we were 
unable to overlook. 
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During Spring 1986 CMU, IBM, DEC and Relational Technology Inc. (RTI) conducted extensive 
benchmarks of the RTI relational DBMS; the results were extremely favorable. Transaction volumes 
and response times were measured over a two week period at DEC and IBM data centers. Because of the 
level of support from DEC and IBM the "benchmarks" really launched the partnership era between the 
CMU Administrative Systems office and major hardware, database and application software firms. 

Following the IBM, DEC and RTI benchmark initiative, CMU felt that some commercial 
applications software firms would be interested in establishing academic/business relationships and 
partnerships related to relational data base Implementations. Commercially available software was 
reviewed carefully and these decisions evolved: 

CMU would not attempt to purchase software at full market price but rather would 

negotiate relationships based on joint participation and resource sharing. 

Opportunities would be explored for joint development, enhancement and/or conversion of 

vendor-supplied software. 

(Commercially available) software packages which could not be acquired without major 
out-of-pocket expenditures or which were functionally or technologically inadequate would 
not be purchased but rather would be designed and developed by CMU staff or jointly with 
vendor personnel. 

The availability of relational data base technology, fourth generation languages, programmer 
productivity tools and a rich VMS and UNIX development environment at CMU had already proven to 
greatly expedite the development process. CMU began the process of functional and technological 
review of existing (commercially available) software. Concurrently, discussions were held with 
commercial software firms regarding future product directions and interest in the higher education 
administrative information systems market. Discussions were not confined to firms already servicing 
the market; new partners were sought and considered. A key part of the strategy was to identify 
niches where competition was not so stiff nor the market so crowded as to nullify the interest of 
firms in the market. 

Prior to 1986, vendors (except for CARS of Cincinnati, Ohio) of software in the higher 
education marketplace had revealed no applications based on relational data bases. SCT has since 
introduced a new product which uses ORACLE as its data base system. The higher education 
administrative systems software market appeared to be dominated by DEC interactive systems and 
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IBM (hardware and) batch oriented (operating) systems. The primary market interest in the relational 
model appeared to be oriented toward IBM's relational products-DB2 and SQL/DS and DEC's RDB. In 
the DEC world, INGRES and ORACLE were beginning to compete heavily with RDB; ORACLE was 
emerging as a key "relational" player in the IBM marketplace, and for that reason ORACLE was 
beginning to enjoy familiarity among higher education administrative systems practitioners. 

The advantages of such partnerships, we believed, were related directly to the perceived 
market value of the future products. CMU continued to seek out commercial (software and hardware) 
partners so as to leverage CMU's technological advantage and perhaps persuade other industry partners 
to participate in the development of new systems. 

Further opportunities may exist for partnerships. Continued evaluation and support of 
relational data base and distributed data base technologies and investigation of lower cost (parallel) 
processors as a means of improving relational data base performance at substantial reductions in price 
performance ratios is also of interest. Discussions with processor firms have resulted in near term 
opportunities for moving current relational products to parallel processors. 

THE RELATIONAL DATA BASE STRATEGY 

Why Relational? 



With date. ;eing stored as a collection of tables in the relational data base, users (programmers 
or end-users) can combine data elements from different tables to new tables or relations allowing 
access to relational^ stored data. Unlike the hierarchical or network storage organization, the 
relational model requires little or no knowledge of the structure of the data base. The fourth generation 
languages when integrated with productivity tools work to facilitate rapid applications development by 
both "relational" data base programmers and end-users. As In the case of the CMU UIS (University 
Information System), once the data base was designed the screens and reports were developed 
expeditiously. The development productivity ratio over conventional PL/1, Fortran and Cobol coding 
are expected conservatively to exceed 2 to 1 in favor of the relational /SQL applications. 

A second major factor in the selection of the relational data base was the portability to a broad 
base of micro, mini and main frame environments (hardware and software). The value of portability 
cannot be overstated. This attribute ensures that applications developed on the PC running MS-DOS or 
the VAX running VMS or ULTRIX or the IBM 3083 running VM/CMS or on the advanced workstation 
running UNIX will not have to be rewritten to run in these other environments. For the first time 
applications will not be constrained when (if) different hardware or operating systems environment is 
d^ated. The proof of portability is in the accomplishment: CMU Is currently moving two major data 
be; 3 applications from VM/CMS INGRES ;o VMS INGRES The movement will be complete by February, 
1988. The results so far are rewarding. 

WHY SQL? 



In most organizations, there Is increasing desire to standardize on a query language for 
accessing data. With the design of the relational database structure, SQL was built to enhance access to 
that structure. In addition to providing a consistent set of semantics for the user, it also was seen as a 
way to provide inter-database communication between various database software vendors. IBM has 
finaily endorsed SQL as the "official" query language standard for relational database systems. In 
1982, the American National Standards Institute chartered the "database committee" to develop a 
proposal for a standard relational language. This committee, with representation from various (dbms) 
vendors, are refining the actual "standard". Although not yet in its final form, SQL plays a major role 
in providing the necessary query tools for clients within the campus to build ad-hoc retrievals against 
the database. 

SQL has been modeled to work well within the relational database structure. Unlike other query 
languages, it builds upon the same syntactic constructs to build complex queries as well as subsets of 
data; it is possible to "nest" retrievals for more defined output. Application developers can move from 
one environment to another without the need for expensive retraining. Applications will become more 
portable, ospecially those developed by third party software vendors and can run unchanged in a 
variety of different hardware and software environments. Since the query language is a standard, it is 
assured of a reasonably long lifetime. 
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As data within more organizations are spread across various machine types, it becomes increasingly 
more important to provide data sharing across those different databases. This task is much simpler if 
the product (from the same vendor) operates across the heterogeneous systems. In the event of 
different database vendors, this function has been impossible. Recently however, there Is a standard 
for inter-dbms communication which exists around the SQL standard. Soon, we hope, applications built 
with tools from one vendor will to talk to other vendor's databases with minimal rewrite and 
interfacing. 



Relational Data Base Firms 
Why INGRES? 

With evaluation of various database products on the market, the range of possibilities were 
narrowed to a few in terms of functionality and operating environments. The requirements were for: 
(1) A wide suite of development tools would exist within the product (2) a product that operated 
across MS-DOS UNIX 4.2, VMS, and VM/CMS (3) data and program portability across those systems 
and (4) a demonstrated commitment to excellence within the product, in terms of regular improvements 
In function and performance. 

The CMU Administrative Systems office chose INGRES as the platform upon which to develop a 
new suite of administrative information systems for all of the reasons cited above. The development 
environment possessed robust 4GL capabilities and programming language interfaces (COBOL, C, 
PASCAL, ADA). INGRES contains an object-oriented approach to all of the internal data dictionary 
elements which operated reliably, as applications were moved across operating systems. It also 
provides end user decision support tools. Internally, some development had been done with specific 
applications based on INGRES and over the past two years with those applications the performance 
increased 50% with each new release. INGRES provides the ability to separate the applications from 
the data structures. With various index structures supported, it was possible to tune indices to match 
the need of the application. Noticeable improvements in performance have been demonstrated. 

We feel that distributed database management may be a key to the integration of different 
computers and operating systems. Distributed database products should simplify data management 
through software that (automatically) tracks information within a network, allowing universal access 
to the information, and transferring control of local information to local machines. Distributed 
database management should impact costs through incremental growth of computing resources. The 
investment in existing resources can thereby b* preserved. We anticipate that the ability to increase 
transaction rates will occur by spreading tasks among several network nodes. INGRES/STAR for 
example, Is an open architecture design that allows extension to support multiple vendors' hardware, 
software and networks. INGRES was designed from Its Inception to support distributed database 
technology. This initial design approach allowed RTI to install their distributed database product 
somewhat In advance of the market. INGRES/STAR has separated front-end applications process from 
the back-end database management software. In this type of architecture, the application asks for data 
using the SQL database language. This architecture allows addition of a distributed database manager 
between the front-end application and several back-end databases. INGRES/STAR supports a 
distributed database manager which allows local INGRES DBMS;; to operate autonomously and provides 
an architectural framework to permit easy access to non-INCRES databases. 

Since INGRES is ANSI SQL-based and provides data base gateways to DB2, RMS and other 
non-relational data base systems, (INGRES) does provide the opportunity for development of industry 
standard data base systems and applications. The SQL compatibility and the INGRES suite of development 
and end-user tools provided the Incentive for a few vendors to seriously consider joint efforts with 



Relational Technology identified the CMU Administrative Systems office as an organization 
which could play a key role in the beta-testing and planning effort of the product. An example of this 
was In the beta-testing performed of their VM/CMS version. CMU provided input as to problems and 
enhancements needed In the product. This input was received by the developers and quick resolution of 
problems ensued. RTPs approach to applying engineering changes In this new version, back into the 
other versions of the product, demonstrated their commitment to excellence in the product. 



WHO CHOSE CMU? WHO DID CMU CHOOSE? 



CMU. 
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The three vendors who expressed interest in a joint venture were: Cyborg Systems, Inc., of 
Chicago, Illinois, Integral Systems, Inc., Walnut Creek, California and Personnel Data Systems, of 
Philadelphia, Pennsylvania. 

These vendors were asked to respond to the HRIS Requirements Document and then were invited 
to CMU for a presentation. The Planning Task Force prepared evaluations of the vendors and made a 
recommendation as to whether the university should purchase one of these systems for the new HRIS. 
Subsequently the planning task force selected CYBORG. The evaluation was conducted on technical and 
functional bases. The financial negotiations came later. 

There were some concerns associated with the selection of Cyborg. The most problematic 
functional areas are multiple appointment processing and distributed processing with multiple approvals 
(i.e. "electronic signature"). In the case of multiple appointment processing, Cyborg wishes to include 
this functionality into a "University module ". Any necessary changes In source code will be made by 
the vendor. CYBORG and CMU will need to jointly research the problems associated with so called 
"electronic signature authorization". 

The Tool Firms 

In developing any new information system, a significant amount of time goes into designing the 
database as well as required functions. In order to expedite the documentation and design process, 
various Computer Aided Software Engineering (CASE) tools were evaluated. DEFT which was 
developed by the company DISUS, Inc. of Rexdale, Ontario, Canada was selected. 

DEFT is a product that provides CASE tools not only for database design but also process 
diagramming and program documentation as well. An object oriented approach is used from system 
conceptualization to delivery. An added advantage is the interface that exists on top of INGRES by 
which Entity Relationship Diagrams are used to generate the actual relational database schemas. Figure 
2 is an example from the UIS application. This provides an excellent way to keep both database 
structures and documentation up to date with minimal redundant effort. 

DISUS chose CMU as a partner based on the accelerated CMU systems development plan over 
the next few years and orientation toward decentralized systems. CMU was thought to be an ideal 
environment to have the product used as the vehicle by which designs and modifications are 
communicated across the campus. In addition, based upon our experiences, CMU will advise DISUS 
about enhancements or improvements needed in DEFT. 

Hardware Firms 

Discussions continue with hardware vendors where their future statement of direction includes 
areas of interest at CMU. Early discussions with manufacturers of parallel processing machines, for 
example, have resulted In the potential for joint development using relational data base systems to 
drive development of new applications. 

Testing of relational data base designs for improvements in both CPU and I/O performance wilt 
be one goal. The second goal strikes to the heart of the Issue of code portability from one operating 
system to another. The new parallel processors tend to be UNIX based; current CMU INGRES 
applications are either MS-DOS, VMS or VM/CMS. The second goal then will be to test the portability 
of the code to the UNIX operating system. 

Other discussions have been held with a variety of hardware firms as new applications appear on the 
horizon. Some of these applications are discussed in "FUTURE 1 ' section of this paper. The key 
strategy here is to explore the best hardware and software solution to the needs of the application 
and not constrain our solutions by the strategic direction of one vendor. 
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WHAT HAS HAPPENED THUS FAR? 



Data Base Development 

In 1983, CMU initiated discussions with various database vendors to determine the future 
directions for each of their products. Specifically of interest to CMU was a statement of direction to 
develop distributed database systems. After long and tedious investigation, by 1985 RTI appeared to 
be the only vendor which offered a clear picture as to the problems and issues related to distributed 
databases; and (RTI) was working on solutions. 

In the same year, we acquired INGRES for a VAX 1 1/780 that was used to build a new space 
management system. Over the course of the two years that followed, we observed the company to be 
one which was focused on the Improving technology of their product. Performance and function 
increased dramatically over the next two releases and we found RTI committed to support the product 
finding and "fixing bugs" with the software in a timely manner. 

As the need arose to replace existing production systems, the strategic decision was made to 
fully utilize the relational database environment. A major effort would include building decentralized, 
distributed information systems that would persist into the next two decades. In doing so, we would 
be relying heavily on the vendor to provide a software product which would meet our needs. Due to the 
technical nature of this effort, the vendor would have to hold an aggressive attitude toward improving 
the product as well. In fact, as we were pursuing our plan we were looking for partners in technology 
to work with us over a five year time period. RTI wanted to work with us to insure that our new 
systems would be successful and necessary enhancements would be incorporated into future RTI 
products. 

CMU has installed new products such as INGRES/STAR and PC INGRES In the past 18 months and 
will participate in the beta test of a RMS Gateway and the next version of INGRES. As application 
development has evolved on INGRES, we have continued to identify problems which surface. Many are 
unique to CMU only because of the large amount of data presently deployed in our database. Support has 
been excellent in resolving these issues. The database vendor has worked with us to understand our 
priorities and issues surrounding those problems. 

Applications Development 

Sigma Systems, Inc., provides software for different computing environments and as a 
result Sigma development staff have acquired a broad range of experience. The Sigma partnership 
brings together CMU and Sigma staff who will work to implement new software. This activity is both 
professionally rewarding and vital for future software product evaluation. 

In part because Sigma did not seek to develop its own database management system, did not 
attempt to design its own scraen handing software, and did not develop each installation as unique 
software, it has been able to adhere to industry standards. The software applications use COBOL, the 
major data base management systems, and many of the mainframe transaction processors. As new 
operating system technology is available, the software could be used merely as an adaptation rather 
than a rewrite of the Sigma application software. New users have been able to implement SQL across 
different data base systems with a modicum of effort. 

Machine Translation (Case 1: COBOL to SQL) 

Carnegie Mellon staff have suggested further automation of the software conversion. A machine 
translation tool was developed by CMU in the course of the SAMS effort in order to expedite the 
adaptation of COBOL-based systems to SQL. Perhaps one of the most valuable pieces of work to evolve 
from the partnerships occurred because of the relational technology strategy. As CMU and Sigma began 
exploration of their partnership, a monumental task emerged of converting large quantities of COBOL 
code to standardized SQL. To adapt and convert a half-million lines of COBOL code by keyboarding the 
changes would not have been feasible within the timeframe allocated for the task and the personnel 
resources which were available at CMU and Sigma. Another tact was clearly called for, even though 
at the time neither Sigma nor CMU had done the research to explore alternatives. 

Clearly some experimentation was necessary and a CMU staff member (Mr. David Campbell) set 
about the task of finding a better way, not only to do the Sigma conversion but other conversions as 
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well. The strategy of partnerships with vendors of existing software raises among other issues the 
issue of starting with other peopled code. 

The basic translator program required about 3 months to write and test by Mr. Campbell and is 
presently converting COBOL statements to SQL statements at the rate of 250 to 300 per minute; we 
feel this compares favorably to the approximately 5 to 10 statements per minute using the traditional 
keyboarding method. 

How are the Partnerships Doing? 

Relational Technology, Inc. 

On June 30, 1986 RTI and CMU signed a five-year (technology partnership) agreement to create 
a distributed database environment that will span the universit/s seven colleges. This agreement was 
the first non-governmental pact to develop integrated information systems based on a distributed 
database environment that includes a variety of mainframes, minicomputers and personal workstations. 
The implementation of this distributed environment intends that "end-users" will have access to 
multiple databases residing on different hardware and operating systems. It is intended that users in 
one department develop applications an*j access necessary data and records from remote departments. 

A majo. development effort is complete which integrates student, faculty and financial data 
within an INGRES database on an IBM 3083. Currently CMU is jointly developing a student information 
system with Sigma Corporation of Los Angeles and a human resource system (HRIS) with CYBORG, INC 
of Chicago. These systems will run on a cluster of two VAX 8700's. 

The RTI partnership has led to use of the INGRES/STAR distributed database, VM/CMS INGRES 
and PC-INGRES (an MS-DOS personal computer product) all of which were beta-tested at CMU in 1986 
and 1987. The effort will use distributed computing resources of the university, moving data from a 
central system to departmental systems and to personal systems. 



SIGMA 

The addition of the recruiting and enrollment modules to the Sigma admissions system should 
affect those institutions which have the need (and skills) to employ such a product. This development 
will result in the first CMU administrative system software product which requires more statistical 
and mathematical understanding than the typical administrative user may possess. This complexity 
presents a problem of user-training even before the product can be marketed and installed; CMU can 
play a role in this transition for other institutions. 

The CMU student records module is not planned as a marketable software product since the 
design approach will be somewhat different than at most colleges and universities. Policy and 
security issues will need to be addressed and resolved on each campus. Many campuses may not be 
philosophically agreeable to the distributed student record system. Decentralization of authority will 
dictate functionality and flexibility which may not be needed for most colleges and universities. 

At the Qui of the project CMU will have a student system based on functional designs which may 
be considerably different than those currently being used and developed. The software and database 
design must permit modification and extensions. The software will facilitate use of the database 
management system tools-query languages, report writers, screen generators-which should provide 
for responsive and productive end-user data processing. A peripheral but nonetheless important 
characteristic of the partnership Iz that the software can be maintained by either Sigma or CMU. 
However a broad market for the CMU student records system will not likely exist. 



CYBORG 

THE CMU/CYBORG relationship to develop a human resource system in a higher education setting 
is a much more conventional approach to vendor/client relationships than the Sigma relationship with 
CMU. It is anticipated the CYBORG Solution Series products will be available with modifications for the 
higher education market place by late 1988. As implied, the CMU/CYBORG relationship calls for, first, 
the enhancement of the baseline product and then the conversion from RMS to INGRES SQL data base 
structures. The main difference from the Sigma relationship is that the relational implementation of 
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SAM Is occurring as the functional enhancements are being introduced. CYBORG is providing 
consultation and review of requirements which may or may not cause tneir source code to be modified. 

THE FUTURE 

Distributed Data Base 

Distributed databases will permit us to take advantage of the parallel processing effect which 
occurs within the software. The query or update command is analyzed by the database optimizer to 
determine how it may be broken down into queries by location (of where the data is stored). As queries 
are split into sub-queries and routed off to the processors where each subset of data exists, results 
can be obtained in parallel and then effectively "merged" together at the requesting node. This would be 
extremely effective in operations where large numbers of records are changed or several levels of 
restrictions are applied to obtain a retrieval. 

Further work is being done to permit the definition of GPU classes in order to determine 
effective processing throughput. This will insure that the same processing load is not expected of a 
small system (e.g. Microvax), as would be a large mainframe (e.g. VAX 8700). In addition, network 
costs such as bandwidth, routers, and gateways will be weighed into the equation by the optimizer. 
This will provide further Information as to which path is optimal for getting the operations completed in 
the fastest time possible. 

Code Management System 

CMU and RTI will jointly work on a code management system to manage software across 
heterogeneous systems. The two organizations share the objective and task of managing software 
development across different hardware and operating systems. Especially with some application 
front-ends residing across many systems (e.g. workstations), and backend software residing on hosts 
(e.g. mainframes), we wish to have an environment in which new software releases are tracked and 
installed with standard automated procedures. 

New Applications and New Partners 

The applications which will benefit from distributed database are numerous. Once the 
university data has been integrated using INGRES, the applications themselves can be migrated onto 
the campus network where students, faculty and staff may access them. The initial applications which 
appear to be likely candidates include: 

• Financial Aid Tracking System - Here information which is relative to the specialized 
needs of the Financial Aid Office is kept on a local department system. This local database can contain 
information such as: interview history data, tracking information, packaging information. The central 
mainframe systems can hold information relative to awards granted, needs determined, and other data 
which is more critical to reside on a larger system. Through the distributed database, both of these 
databases will reside in the same overall database that allows the applications and clients to access 
information transparently. It aids in isolating critical components of the system without eliminating 
access. Disk space for information required only by the Financial Aid (FA) department may be used by 
that department; FA can control the rate of consumption. If all space is consumed, it does not preclude 
processing which is necessary as part of the overall campus operation. 

• Degree Audit Tracking - Departments may maintain degree requirements upon their own 
workstations or local file servers. As these requirements are available, they are used periodically by 
the central systems for course registration validation or transcript preparation. Locally they provide 
immediate verification of courses outstanding to students as well as assist in advisir.g students what 
choices are available in transferring from one program to another. A micro-based, PC-AT, degree 
audit system application has already been implemented. 

• Student Records Data Entry - The data entry process for student records information 
will be moved out of the Registrar's office to the various campus units. By using distributed database 
to ensure transaction integrity across the network, it will be possible to access translation tables for 
various validation codes either locally or cached locally after retrieving from the central system. Once 
data has been entered, the data may be either: (1) stored in a local table, and then updated, applying 
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the set of entries, against the central database, or (2) updated, in real time, against the production 
database. Typically one could think of both types of transactions occurring depending upon the time of 
year. 

• Cashless Campus - Distributed database can link databases which interface with different 
applications depending upon the intended usage. With one objective being n debit card" services using a 
student/faculty/staff ID card, various databases may exist for specific purposes. Food Service will 
keep information relative to contract meal plans, cash balances targeted toward meals, inventory, and 
sales transactions. The Campus Bookstore will keep data that is relative to cash balances targeted 
toward purchase of books and supplies, sales transactions, and inventory. The parking office may keep 
an authorization database indicating patrons of various campus parking lots. All of these systems will 
require transaction interface to the Student Accounts Receivable system. It may be possible that the id 
card technology is used as the ultimate form of authorization granted by an individual to access his/her 
personal information. 

EPILOG 

The opportunity to develop a new generation of administrative information and management 
support systems has been made possible in part by the timely allocation of University seed money. 
The confluence of recognition by the senior (CMU) administrators of the needs and the opportunities 
provided by the current (and near future) technology will foster a new and more effective managerial 
information model. 

The technological and economic leverage provided by the adaptation of relational and eventually 
distributed relational data base systems is pervasive. Creating systems and applications in an 
environment e. g. INGRES has already reduced the need to completely reprogram or convert 
applications, if and when new hardware or operating systems are dictated. We believe that large 
scale administrative applications tend to last longer (2 to 4 times) than hardware systems. The 
financial and operational advantage of long term application tenure should not be overlooked. 
Indications are that many application software vendors agree and thus will create more portable 
applications in the future. Proprietary software/hardware/data base combinations will find niches but 
not broad markets. With funding provided by tho University 10 create the data base environment and 
with help from the industry partners in place the momentum exists to create a new generation of 
administrative systems. As this momentum and its concomitant energy manifest in new applications 
software, ths piomise of the technology will be fulfilled haung been made possible in large part by the 
partnerships. 

The development and migration of applications and data b^ses from the central to the distributed 
environment will be cer'cally coordinated; the complete migration is expected to span the 5 year 
period from 1986 through 1990. 
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Abstract 

The Virginia Cooperative Extension Service (VCES), operated jointly by 
Virginia Tech and Virginia State University, is pursuing high technology to 
help meet its mission of providing practical information to the people 
of the Commonwealth to improve their economic, social, and cultural well- 
being. Since 1982, VCES has been engaged in a variety of electronic projects 
to enhance its program management and delivery capabilities. The following 
are examples of VCES' technology projects, which will be described: 

• In 1982, six Extension field offices were connected to VCES' computer 
network. By 1984, all Extension field offices (120), including offices in all 
the counties of Virginia, were equipped with personal computers and were 
linked to the Virginia Tech mainframe. 

• C-band satellite receiving dishes were installed at 41 Extension sites dur- 
ing 1987. The teleconferencing system is providing oroadcast capabilities 
for educational programs and staff training sessions from Virginia Tech's 
campus to the Extension offices across the state. 

• VCES began, in 1983, transferring computer files with educational infor- 
mation from the Extension network to a single newspaper. Today, news 
releases are electronically transferred to six major Virginia newspapers 
and the United Associated Press, ensuring the printing of timely informa- 
tion. 

• In 1985, VCES aggressively began to pursue interactive video as a poten- 
tial method to expand its audiences. During the next threo years, VCES 
will develop interactive video public information kiosks to be located in 
shopping malls and in libraries. 

VCES' strategy is to stay diversified and try different technologies as 
they arise. The successful adoption of these technologies has resulted from 
administration's commitment, staff's involvement, support from other technol- 
ogy groups, using early adoptors to teach and promote, the use of pilot 
projects, and systematic evaluation. In summary, VCES' plan to integrate fu- 
ture emerging technologies into VCES' program delivery system will be dis- 
cussed. 



Extension Use of Technologies 



Virginia Polylechic Institute and State University (Virginia Torh), a publicly supported, com- 
prehensive, land-grant univeisity, serves the Commonwealth of Virginia, the nation, and the 
international community by generating and disseminating knowledge in the basic human, 
social, and scientific disciplines through instruction, research, and Extension. Virginia 
Tech's land-grant missions are supported by aggressive strategies to develop computing 
and communications networks. The Virginia Cooperative Extension Service (VCES), oper- 
ated jointly by Virginia Tech and Virginia State University, is pursuing high technology to 
help meet its mission of providing practical information to tho people of the Commonwealth 
to improve their economic, social, and cultural well-being. 

Since 1982, the Virginia Cooperative Extension Service has boon engaged in a variety of 
electronic projects to enhance its program management and dolivnry capabilities. VCES' 
technological projects include a statewide computer network, computer linkages to infor- 
mational data bases, satellite teleconferencing, interactive video applications, electronic 
transmission of information to news outlets, computer linkages with other federal and state 
agencies, and local area networks. 

Statewide Computer Network 

In 1982, VCF.S undertook a five-year project to develop a statewide computer network. The 
network was planned to connect ail the Extension field and campus offices to a single com- 
puter system. 

VCES has 120 field offices-108 county/city offices, six district off ic ns, and six 4-H Educational 
Centers. Today, each of these offices has at least one standard hardware workstation. The 
standard hardware configuration includes an IBM-PC with two double-sided 5-1/4" floppy 
disk drives, a color monitor, a 1200-baud modem, and a dot-malrix printer. All of the PC's 
are equipped with an AST SixPackPlus expansion board which provides a serial and a par- 
allel port, a hardware clock, and memory expansion. In addition to this standard package, 
forty offices have an IBM-PC/XT with a 10-megabyte hard disk drive, and 20 IBM-PC port- 
ables are being used by area farm management agents. Earlier generation hardware, which 
remains in use, are 48 full-screen terminals. 

All Extension field offices are connected to the Virginia Tech computer system. The tele- 
communications connection to Tech's mainframe provides all Extension staff with access to 
the resources of the Virginia Tech Computing Center. The primaiy computing facility at the 
Center is an IBM 3090 multi-processor complex. 

The majority of the Extension field offices have only one personal computer, and these are 
typically used for office management functions; wordprocessing. mailing list management, 
etc. To make maximum use of the personal computers, each Extension office in the state 
has been supplied with the following microcomputer software packages: YTERM, a com- 
munication package; LOTUS 1-2-3, a broadly applicable spreadsheet program; PC-FILE III, a 
flexible, but inexpensive, data base management program; PCXEDITOR, a screen editor for 
the PC which resembles IBM's XEDIT editor for its CMS operating systo.m on the mainframe; 
and WORDPERFECT, a wordprocessing program. 

Computer Linkages 

Extension has experimented with severe methods of sharing computing resources: trans- 
ferring information from other mainframes to the Tech computer, networking to other 
mainframes, and networking personal computers. Extension makes use of two nationwide 
computing systems, DIALCOM and ACRES, ny moving information and data to the Tech 
computer. DIALCOM, owned by IT&T, is a computer network which is used by Extension 
personnel throughout the U.S. The USDA news releases and OUTLOOK information are 
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downloaded daily from DIALCOM' and redistributed via the Viiginia Extension Computer 
Network. ACRES provides information and agricultural news. II is operated by Farm Bureau. 

Recently, Extension has begun to investigate the use of gateways to othei computer systems 
via the Virginia Tech computer. In June 1987, a telecommunic.nlions link was installed be- 
tween the Virginia Tech and Virginia Department of Agriculture and Consumer Services 
(VDACS) computers. The computer link is a joint project by Virginia Cooperative Extension 
Service and VDACS. Virginia Tech's Communication Network Services (CNS) Group in- 
stalled the link and will maintain the communication equipmonl. The link provides electronic 
communication between VCES and VDACS computers and Iho sharing of computer applica- 
tions. 

Extension, using the University's BITNET node, also has electronic, mail and file transfer ca- 
pabilities to the majority of the other land-grant instilutions. Pmsnnlly, VCES is exploring the 
use of the National Science Foundation and the Southern Univnisily Research Association 
computer networks to share computing resources within Iho Soul horn Extension Region. 

Local Area Networks 

Extension has also experimenled with the networking of personal computers. The 
Chesterfield Extension Office is the site for the 'Computerized Fxlension Office,' a model of- 
fice developed to provide information for future computer development. Each agent's, sec- 
retary's, and technician's workstation is equipped with an IBM-XT, linked by a local area 
network. The XT's provide all staff members wilh sufficient computing power and storage 
for their own work, and the network links the workstations to a laser printer, a modem lo link 
to the Virginia Tech mainframe, and shared data bases on the other hard disks in the office. 
The Chesterfield network was installed in June 1986 and a token ring network was installed 
in the Chesapeake Extension Office in June 1987. 

These two test sites are providing valuable information about Ihe usefulness of local area 
networks and office automation in an Extension office. Due lo tho success of these two pilot 
efforts, in the near future, similar networks will be installed in al less one additional office 
and several less sophisticated networks will be installed in smaller offices to share printers 
and storage devices. 



Satellite Broadcasting 

The creation of the Virginia Tech Telcport Facility and the installation of a 9-meter diameter 
C-Band satellite uplink anlenna, in 1986, provided the initial impetus for tne Virginia Coop- 
erative Extension Service to explore the usage of satellite technology for information and 
program delivery. The u~link she presently provides two, broadcast-quality, video signal 
channels for transmitting NTSC standard television signals from Placksburg. The vision, and 
now the reality, of Virginia Tech developing its own multi-pur pose satellite communications 
network affords VCES numerous opportunities lo explore Iho ninas of information dissem- 
ination and educational program delivery. 

In the summer of 1986, approval was given by the Extension administration to fund the 
placement of 25 downlink sites (at least one per planning dislric.t). to be located in local Ex- 
tension offices, 4-H Educational Centers, district offices, and research stations. Sixteen ad- 
ditional downlink sites were proposed, approved, and became operational in October 1987. 
Of the 41 downlink silos located across the Commonwealth, 3 are located in district offices, 
4 in the 4-H Educational Centers, 4 in research stations, and 30 in local Extension offices. 

Using Virginia Tech's television studio and electronic classrooms on campus, VCES began 
broadcasting teleconferences for Extension staff in April 1987. Presently, an average of four 
programs are aired each month. Satellite broadcasts from ollmr State Extension Services 
are also promoted and viewed at Virginia Extension sites. The n< coptance and effectiveness 
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of satellite educational programs are being evaluated for Iho fiisl y^ar to provide future di- 
rection for the satellite teleconference system. 

Electronic Transfer 

The Virginia Tech Extension Information Office (EIO) produ<.es <uul distributes Extension ed- 
ucational information to newspapers, radio, and television outlets across the Common* 
wealth. In 1982 and 198x3, computer terminals were installed in Ihe EIO Offices. Given this 
computer capability, the office began to investigate the feasibility of electronic transfer of 
news releases. 

Two major premises were established for the electronic transfer program. First, EIO would 
try a proactive system; i.e., a system in which new releases would be dumped to news outlet 
computers, rather than have the outlets access the Virginia Tech computer to select stories. 
Secondly, news outlets were approached on the basis that a customized service would be 
provided to meet the outlets' needs. 

The service was accepted first by the Roanoke Times, a regional v paper, and today six 
major Virginia newspapers and the United Associated Press are \ . ig the service. This 
program guarantees the timely delivery of Extension information. 

The EIO Office also electronically provides infoimation to each Extension office in the state 
via the Virginia Tech computer link. The electionic link offers the EIO Office the opportunity 
to quickly get infoimation to small dailies, weeklies, and broad: nst stations via Extension 
agents. 

Interactive Video Project 

A project was planned in 1985 to actively investigate interactive video as an educational tool. 
The successful development of a demonstration model led to VCE3 being awarded a $1.2 
million grant from the W. K. Kellogg Foundation for the development of public information 
stations to enhance the information delivery structure of Extension. The thiee-year grant 
began April 1, 1987, and employs new technology in information systems that facililale 
problem solving. The technology upon winch these systoms will bo leased is referred to as 
"interactive video." This technology integrates largo quantities of video, slides, graphics, 
voice, and text, pei milting a microcompuler to coordinate Iho material for tailoied presen- 
tations to individuals. Systems based on this technology are good candidates for public in- 
formation stations because of the vast amount of information which can be stored on the 
laser disc. 

The delivery stations will be located throughout the state in shopping malls and libraries. 
This selling will provide the opportunity for clientele to receive infoimation in places and at 
times convenient to them. It is anticipated thai, during the first year. 12 stations will be 
placed in the stale, with additional stations being added each of Iho remaining two years. 
The systems located in malls will be packaged in such a manner that those interacting with 
the system will only need to touch the screen to select progiam options or control the 
presentation. Systems located in libraries will have the added capability of keyboards and 
voice recognition. 

Program material will be developed in three main areas, consumer questions and concerns; 
horticulture; and health and nutrition. One area will be developed and tested during each 
of the three years. 




ERIC 



441 



Strategy for Technology Implementation 

VCES' approach to implementing information technologies emmged from the development 
of a statewide computer network which began in 1982. The long range goal was to develop 
a computer network to enhance the delivery and management of Extension programs. The 
short-range goal was to meet present demand for computer-aided programs with existing 
hardware or hardware that was expected to be compatible with the network system and en- 
courage software development by Extension staff. 

These goals, developed in early 1982, which seemed very global at the time, have proven to 
be a very successful formula for implementing technologies foi I he Extension organization. 
The following statement from Virginia Tech's, "An Information Systems Strategy," drafted in 
1985, describes the approach that VCES and the University has taken toward technology 
implementation: 

"Classical approaches to planning usually emphasize the establishment of 
goals. In a time where technology is growing and changing so rapidly, such 
a static approach is clearly myopic. What seems more fruitful is a strategic 
view of the University's computing and communication fulure-a view that at- 
tempts to articulate a growth philosophy that permits seizing opportunities 
when the state of technology is right. Some technological advances are 
clearly predictable; others are not so easily foreseen. Whatever strategic po- 
sition the University assumes, vis-a-vis, computers and communication, it 
must be predicated on foreseeable technological advances, and flexible 
enough to accommodate those that are not so easily discernible." 

VCES' strategy to stay diversified and remain flexible to permit seizing opportunities when 
the state of the technology was right has enabled the organization to be in a position to im- 
plement emerging technologies, but the keys to successful implementation has been Ex- 
tension administration's commitment, staff's involvement, supportive relationships with 
other technology groups, early acloptors' participation, the use of pilot projects, and evalu- 
ation. 



Administration's Commitment and Staff's Involvement 

It is well documented lhat the administration's commitment and the involvement of staff at 
all levels are critical to any major orgarvzalional change. Commitment and involvement are 
paramount in the implementation of new technology because of Ihe financial resources re- 
quired, the rapid emergence of now technology, and the dramatic change in staff's skills and 
behavior required. Conscious steps have been planned and executed by VCES' adminis- 
tration to demonstrate its commitment to technology development projects and a high pri- 
ority has been placed on the involvement of staff, as illustrated by the following: 

• All staff received a letter from Extension's Director which described the statewide com- 
puter network as a top priority for the organization and a 25 member task force was ap- 
pointed to provide direction for the project. 

• The first step VCES took toward exploring interactive video was lo invite about forty key 
staff members to a demonstration by a corporation that had successfully developed 
interactive video for staff training. The enthusiasm for the potential of interactive video 
rapidly spread throughout the organization. 

• The satellite downlink project was announced at an annual staff conference only two 
days after a decision had been made to move forward with the project. Extension's total 
staff assemble only once a year. Using this opportunity lo announce the downlink 
project eliminated "grapevine" misconceptions-everyone Wris told the whys and hows 
about the project at the same time. 
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'* The strategy of clear communication to all staff at the beginning of a project was also 
used with the interactive video public information project. The project description and 
scope v~re discussed with staff by VCES' Director during Extension's first satellite 
broadcast teleconference. 



Relationships with Other Technology Groups 

To support its educational mission, Virginia Tech has excelled in the development of com- 
munications systems, computing, and state-of-the-art instructional support services. These 
advancements have been paralleled by the growth of the University's technology support 
staff. Extension, recognizing the University's vast resources and resisting the temptation to 
"go-it-alone," has heavily relied on the assistance from other technology groups within the 
University. The following are examples of how Extension has benefited from the assistance 
of the University's communications, computing, and other support groups: 

• In 1981, with the plans for an Extension statewide computer network on the drawing 
board, Extension computer applications housed on a privately leased computer needed 
to be converted to the University computer system. Virginia Tech's Systems Develop- 
ment Group supervised the conversion of over seventy-five computer programs. 

• The Virginia Tech Communications Network Services Department, which is responsible 
for the Universe's voice, data, and video communication systems has been instru- 
mental in the design of data communications networks to accommodate Extension's re- 
quirements to connect its 120 statewide offices to the University's mainframe. 

• The University's Computing Center's User Services staff have conducted training ses- 
sions for Extension field staff at off-campus locations. This group traditionally provides 
user assistance for on-campus graduate staff and faculty. 

• With the installation of Virginia Tech's satellite uplink facility, a demand was created for 
satellite broadcast based programs. The potential for broadcast capability was obvious 
to Extension with its decentralized office arrangement. At Extension's request, the CNS 
Department deployed a team to design and install satellito receiving dishes at 41 Ex- 
tension sites. 

• For the past two years, a full-time CNS faculty member has been assigned to Extension 
to study and implement off-campus voice, data, and video communication needs. As an 
example of this work, the faculty member has designed and installed two local area 
computer networks at Extension offices. This arrangement has given the CNS manage- 
ment a better understanding of the University's off-campus communication needs and, 
at the same time, Extension has benefited from the technic?! assistance. 

• In 1985, when Extension discovered the potential for interactive video to reach new au- 
diences in a decentralized program delivery mode, resources were found within the 
University's Learning Resources Center (LRC) to assist with an interactive video probct. 
The University's LRC Group had been experimenting with interactive video for several 
years and generously shared their experiences. Currently, LRC is cooperating with Ex- 
tension staff on the public information interactive video project, providing video pro- 
duction and instructional design assistance. 

• The LRC staff are also very involved in Extension satellite programming. The programs 
are aired from the University's studio or electronic classroom and are produced by the 
LRC staff. 
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Participation of Early Adopters 

During the implementation of Extension's statewide compute* network, there was an obvious 
shortage of staff to conduct training and provide daily user support. With limited resources 
available, Extension elected not to make significant staff additions. One faculty member was 
hired to coordinate training, but hardly one person could have boon expected to provide 
training for staff housed in 120 different offices across the state. The lack of users' support 
created frustration for the staff, but over time an informal learning network developed. The 
early adoptors of computers did not wait for additional formal training, but resorted to self- 
instruction and user groups to expand their knowledge of computers. In shor* ,ith the 
leadership of these early adoptors, staff organized themselves to deal with the void. Exten- 
sion realizes the existence of early adoptors within its organizalion and other organizations 
and uses these resources, illustrated by the following: 

• One of the major problems with a decentralized computer network is the logistics of 
providing training and other support functions. To address these problems, Extension 
has identified staff within the off-campus offices to assist with training, equipment in- 
stallation, resolving software problems, and, in general, promoting computer applica- 
tions. These staff include secretaries, Extension agents, and faculty. Typically, these 
staff members were the early adoptors of computers and self-educated to become 
computer literate. 

• In most cases, Extension's technology pilot project sites worn selected because the staff 
at those chosen locations had reputations as early adopiors. Using early adoptors for 
pilot projects minimized the effort required to deal with resistance to change. 

• The Extension Computing Resources Office uses early adoptor staff to test newly devel- 
oped software. 

• For each satellite downlink site, a programming coordinator was identified. Staff were 
selected as coordinators based on their reputation as innovators. The coordinators loles 
are to: identify audiences, actively promote satellite broadcasted programs, involve 
other staff to expand the appreciation for the delivery method, and create a total educa- 
tional program around each broadcast. 

• A computer link was successfully established between Virginia Department of Agricul- 
ture and Consumer Services and Extension, because the staff from both organizations 
involved in the project could see the potential for such an electronic linkage. A con- 
scious decision was made to avoid staff that would constmct barriers, resisting the 
technology. 



Use of Pilot Projects 

Pilot projects have been used extensively by VCES to test emerging technologies and posi- 
tions the organizairon for full-scale implementation. In addition to the obvious benefits of 
pilot projects, VCES has seen that pilot projects heighten staff awareness of new technolo- 
gies, visibly demonstrate the administration's commitment to new modes of operations, and 
prepare staff for future change. Pilot projects also permit the organization the option of 
abandoning a technology if it doesn't develop as anticipated. The following are examples 
of VCES pilot projects: 

• VCES' statewide computer network began with six offices equipped with computer ter- 
minals and dial-in capability to Virginia Tech's mainframe. The pilot project readily 
identified problems associated with a decentralized operation-equipment delivery and 
installation, telecommunications problems, staff training, and hardware maintenance. 
On the positive side, the benefit of electronic communication of timely information, the 
usage of a hi-tech office, and the increase in staff morale were observed. 
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• In 1982, VCES purchased several multi-user and personal computers and tested both 
systems in field offices. Although, at the time, the multi-user microcomputer seemed the 
reasonable approach, the 'PC emerged as the standard. VCES was in a position to 
move rapidly and implement PC based systems. 

• With the widespread use of personal computers and the abandonment of multi-user 
micros, VCES installed a PC network in one Extension field office in 1986. The pilot 
project allowed VCES to identify how local area networks could benefit the local offices' 
office management and program deliveiy computer operations. Also, the experiment 
yielded a working configuration that could be replicated. The success of the project was 
recognized by another Extension field office which obtained funding to install a network 
patterned after the pilot configuration. 

• Extension's use of interactive video systems for information delivery began with the de- 
velopment of a demonstration model. The model was used to evaluate hardware and 
software components, but, more importantly, the model demonstrated to staff the con- 
cepts of the merging of computing and video technologies. Having successful demon- 
strated the potential of interactive video with the pilot test, private funding was obtained 
to fully implement several public information systems. 

• This summer a telecommunications link was installed between the Virginia Tech and 
Virginia Department of Agriculture and Consumer Services (VDACS) computers. The 
first computer application where both agencies computers will collect and share data is 
not expected until January, but there is already growing interest in additional applica- 
tions using the linkage. 

• A pilot project has recently been started with desktop publishing. The purpose of the 
project is to develop operating procedures for regional desktop publishing. The project 
will include testing methods for electronic routing, evaluation of desktop publishing 
systems, determination of training requirements, and documentation of staff acceptance. 

Evaluation 

The Extension organization, national and state, places a high priority on evaluation as part 
of the program planning process. All Extension staff annually develop plans of work, which 
includes planning, implementation, and evaluation components. Likewise, Extension's 
technology projects have included evaluations: 

• An initial step in Extension's computer project was to conduct a needs assessment. The 
study focused on the question, "How can computers increase the organization's effec- 
tiveness and efficiency?" The results of the study have been, for five years, to set pri- 
orities for computer equipment and software. 

• Evaluation results have been use to justify expenditures for technology projects. 

• One-quarter of a faculty position has been assigned to Extension's public information 
project to evaluate the project. 

• An extensive evaluation, using qualitative methods, was conducted of the local area 
network project. The evaluation tracked staff's reactions and behavioral changes. 

• Currently, a study is being conducted to determine how staff are using electronic mail. 
The results will be used t^ assist staff in their determination of appropriate communi- 
cation methods. 
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Future Plans 

For the past five years, VCES has taken a diversified approach to implementing emerging 
technologies and has maintained a flexible position in order to expand its use of proven 
technologies. Realizing the vast number of technological advancements on the horizon and 
not willing to be content with past successes, VCES organized a task force last Spring to 
develop strategies for implementing emerging technologies. On November 18, 1987, the 
committee's report was presented to the Extension Administration. The following is a sum- 
mary of committee's recommendations: 

Needs Assessment - Some would say that VCES has been driven by new technologies- in- 
stalling hardware and then asking the question, "How can this technology be used?" In or- 
der to seize opportunities, VCES has moved quickly to implement several technologies. 
Now, with a variety of program delivery methods in place, VCES must determine informa- 
tional needs and preferences of clientele, and assess current and future information delivery 
methods to determine their appropriateness and effectivene$>s. 

Resources Networking - VCES has just recently began to investigate linkages with other 
computer systems, but already recognizes a great potential for sharing resources. VCES 
will continue to pursue computer links with other agencies, institutions, and organizations 
for sharing of information and data bases. VCES will also actively explore strengthening 
relationships with other agencies to foster the cooperative efforts in research, data col- 
lection, and standardized information delivery mediums. 

Inform at ion Delivery Systems - Emerging technologies are rapidly changing the way we think 
about delivery of educational information. Extension should continue to develop, implement, 
and evaluate electronic systems to increase program delivery capabilities, efficiencies, and 
effectiveness. The greatest challenge will be the establishment of standards and coordi- 
nated procedures to permit the employment of multiple approaches to information delivery. 

Knowledg e Base Systems - Computer-assisted instruction (CAI) and computer-based training 
(CBT) are an integral t art of many organizations, providing alternatives to training personnel 
at a distance. Also, computer technology offers new options for diagnostic services, poten- 
tially replacing one-on-one personal contact services. The potential for successful 
computer-assisted instruction and knowledge systems within VCES are numerous, yet mini- 
mal effort has been devoted to this area, systems. As an outgrowth of VCES's interactive 
video, increased activities are expected in the areas of laser disk and expert systems. 

Staff Development - Two major challenges exist for Extension related to staff development 
and emerging technologies. First, programs need to be expanded to maintain staff's com- 
petency in applying various technologies. Secondly, VCES should utilize the appropriate 
technologies in providing staff development opportunities. 

Capital Budget - For the past six years, VCES has had a modest capital budget for technology 
projects. Today, the number of technologies competing for those dollars is increasing. 
VCES should establish capital budgets to iecognize the fiscal demands required to maintain 
a diversified and flexible position. And, VCES plans to develop a procedure for prioritizing 
capital expenditures and allocating development funds. 

Organization Structure - The present VCES technology support groups have evolved over the 
years without serious considerations being given to the organizational structure required to 
support emerging technology projects. An organization should be put in place that comple- 
ments the incorporation of new technologies. Responsibilities for development, implemen- 
tation, support, staff development, and evaluation should be clearly defined. 



Summary 

VCES, like many organizations, is at a crossroads related to the implementation of technol- 
ogies. Many of the questions related to computing and communications are much clearer 
than in the past. The majority of the computing needs for Extension can be handled by per- 
sonal computers or networks of personal computers. Computer linkages to centralized 
mainframe computers can provide the major computational services and repositories for in- 
formation data bases, at least for tho short term. Communication networks are in place; al- 
though, separate and relatively expensive. We are now in an information era with 
technologies merging to create information systems - incorporating activities in computing, 
communications, data bases, and new data storage alternatives. 

Any strategy for the future needs to consider how communications and storage media tech- 
nologies will advance and how they will be integrated. Information systems strategies will 
force decisions regarding how information will be stored and retrieved. 

The development of strategies for the future technologies in VCES will start by addressing 
the following questions: 

• What methods of information delivery are acceptable to staff and clientele? 

• To what extent should voice, data, and video communications be merged? 

• What is the future for two-way video systems? 

• Where should information be stored? 

• What are the cost considerations for communication systems compared to decentralized 
information data bases? 

• How can decentralized data bases be updated? 

The answers to these questions are expected to direct VCES to a flexible position for tech- 
nology implementation for the next five years. 
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FOURTH G ENERATION LANGUA GES IN A PRODUCTION 

ENVIRONMENT 
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SQL and DB2 are touted as the productivity tools to 
cure the "ills" of long application development cycles 
and of user-unfriendly software. Relational database 
management packages which use 4GLs are said to "have 
come of age." But where are the large applications in 
production today to verify or to demonstrate the 
stated advantages? This paper: 

(1) explores the literature for and against 4GLs; 

(2) describes several large applications written 
with 4GLs; 

(3) details the San Francisco State University 
experience of creating a Student Financial 
Aid application using ORACLE, a relational 
DBMS which uses SQL, 

Both hardware and software aspects of the new 
development tools will be dibcussed. 
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FOURTH GENERATION LANGUAGES 
IN A PRODUCTION ENVIRONMENT 



INTRODUCTION 

During the last few years r much of the popular MIS literature 
has focused on software methods to increase data processing 
efficiency and information availability. Terms such as 
"fourth generation languages f n "user friendly interfaces" and 
"database management systems" have been thrown about r often 
in the same paragraph as references to 30:1 improvements in 
programmer productivity. 

This paper first presents a commonly used f ramf>v:or:k to 
explain "what the shouting's all about." From that 
foundation, it next focuses on the use of one 4GL r the 
Structured Query Language (SQL) , by two relational database 
management systems , DB2 and ORACLE. Specif ically f the extent 
to which these software packages are being used in a 
production environment in both industry and in institutions 
of higher education is explored. Finally r the ORACLE 
implementation of a Financial Aid system at San Francisco 
State University is described in detail. 



WHAT IS A FOURTH GENERATION LANGUAGE? 

The 4GL attempts to solve many of the problems of the 
traditional application development cycle. "Third 
generation" procedural languages such as COBOL, combined with 
file structures such as ISAM and VSAM, have been the work 
horses of DP shops for more than a decade. Unfortunately, 
the development cycle for a 3GL application is quite lengthy, 
and is not easily accommodated to changing user 
requirements. 

For the purposes of this discussion, the important elements 
of a 4GL are: 

(1) a database management system (DBMS); 

(2) a data dictionary; 

(3) a query language; 

(4) a screen/report generation facility; and 

(5) a programmer's "workbench." 

(1) A DBMS , The first item on the above list, the DBMS, is 
critical to the 4GL because it allows data relationships to 
exist independently of applications and facilitates data 
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sharing with concurrency control. The DBMS thus allows 
application developers to concentrate on products more than 
on the physical structure of the data.. Users access views of 
the data, also controlled by the DBMS. 

Two models are common for DBMS packages: hierarchical and 
relational. A hierarchical DBMS, such as IBM's Information 
Management System (IMS) or Information Builder's FOCUS, 
presents data to users in a tree-like structure. To the 
user, each record resembles an organization chart; the top 
level is known as the "root" which identifies the record and 
may contain the most commonly accessed information in the 
record. Lower level segments of the record ("child" or 
"dependent") contain some set of data elements that are 
logically related to each other. 

The hierarchies.! model allows variable-length records 
consisting of one root segment plus any number of dependent 
segments. The DBMS accomplishes this flexibility by using a 
set of pointers, chains, physical positioning, directories 
and bit maps that indicate connections, it is up to the data 
base designer to establish physical data base representations 
that result in processing efficiencies, to group data 
elements that are logically related, and to create segments 
by considering how data will be accessed by application 
programs. Paths, or logical views, are defined by the types 
of data base segments that can be accessed and by the kind of 
access that is permitted, such as read only, read/write, etc. 

The two major advantages of the hierarchical model are: (a) 
it is a well established concept and implementation, and (b) 
it handles large volumes of data efficiently. The major 
disadvantage is that the supporting data structure is 
inflexible and requires substantial planning for optimum 
performance. 

The relational DBMS, such as IBM's DB2 and Oracle 
Corporation's ORACLE, presents data to users in the form of 
tables of rows and columns. This is a more user oriented 
view. The user is isolated from the physical storage of 
data. A table consists of one record type, housing a fixed 
number of fields. There is no explicit sequence by which 
rows (records) within a table (file) are organized. A set of 
tables can be accessed by specifying relationships between 
tables in order to develop useful sets of data. 

There are three basic operations that a user can specify in a 
relational data base: Select, Project and Join, in each, 
one or more tables are manipulated, resulting in the 
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formation a new table. The Join operation best 
illustrates the power of a relational DBMS. It takes full 
advantage of the segmentation of data into usable pieces 
(tables) that can be retrieved and combined when necessary. 
The user then extracts information of interest from a table 
containing "joined" elements from database tables. 

Flexibility is the major advantage of the relational model. 
It can easily adjust to changing information requirements. 
Unlike hierarchical DBMSs f relational data bases are not 
built with a limited number of logical views or access 
paths. Their access paths are specified by the user. This 
flexibility contributes to the major drawback of this model, 
which is performance. Users may not select the optimal 
access path f and may not state their data requests in the 
manner most efficient for the DBMS. The DBMS must do more 
work for the user f which impacts the performance of this type 
of data base. 

(2) A Data Dictionary . The data dictionary is a mechanism 
for defining data attributes and establishing relationships 
between data items. The data dictionary serves the important 
function of specifying, in a central location, such things as 
the types of validity checks that have been applied, who has 
update rights to the data item, security levels imposed and 
other names by which this data item is known. These 
attributes of the data item are provided when placing it in 
the data dictionary. 

(3) A Query Language . A high level query language is 
generally defined as a user-oriented facility for the 
creation and retrieval of data in a data base. Extending 
this further , a high level query language also provides 
transparent navigation of a data base as well as a 
"natural-language-like" qualification of the query. SQL f the 
Structured Query Language that is the main interface to both 
IBM's DB2 and Oracle Corporation's ORACLE , has been accepted 
as the American National Standards Institute (ANSI) standard 
database manipulation language. 

(4) A Screen/Report Generator . A 4GL must be able to paint 
screens and generate reports with ease. The screen painting 
facility allows the creation of appropriate display screens 
for the entry and/or presentation of data or information. A 
report generator provides similar capabilities for 
information derived from the data. These features should not 
be dependent on an application generation tool; they should 
allow access to data stored or to be stored in the data base 
without the need to generate application code. 
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(5) A Programmer's "Workbench", This component of a 4GL 
environment contains tools to increase the cost effectiveness 
of programmers. Commonly f a "debugger" for researching code 
errors is among the utilities in the workbench. Code 
generators have been another major innovation. Application 
development systems, the next logical step f allow the 
construction of entire application systems or subsystems 
using "canned" subroutines that have the potential of cutting 
coding time by forty percent. Finally, the ideal 4GL also 
includes a tool that improves the production of system and 
user documentation. The combination of the data dictionary 
and the righ*: tools from the programmer's workbench can 
virtually automate the production of documentation. 



WHERE ARE THE SQL PRODUCTION SYSTEMS? 

As was mentioned in the Introduction to this paper , only two 
relational database management systems using SQL will be 
discussed here. A general description of the requirements of 
each product , DB2 and ORACLE 9 is given below. 

IBM released its relational DBMS product, DB2, in 1983. 
Judged by the industry to be a "relatively lackluster" DBMS 
offering since 1983, IBM announced a new release of DB2 in 
1986 which improved its performance sufficiently that IBM 
repositioned DB2 as its broad-based, production-level 
database management system. The products which define DB2 
include: 

(1) Structured Query Language (SQL); 

(2) Data Extract (DXT); 

(3) Query Management Facility; and 

(4) Utility programs that facilitate workstation access. 

To implement these four products , operating system releases 
must be carefully synchronized. For example, DB2 requires 
MVS/SP Release 1.3 or MVS/XA release 1.2. To use the Query 
Management Facility, GDDM Release 3 is required. If CICS is 
to be used, then its Release 1.6 is required. 

To estimate the storage space required for a DB2 
implementation, Walsh (1987) recommends: "Determine how much 
it costs to store information in existing data base 
structures or files and simply triple that amount for the 
number of months it will take to complete the 
conversion. . .the rule of thumb is that a DB2 data base 
requires twice as much space as an equivalent sequential 
file." 
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The ORACLE product has been available since 1979. Its first 
release by Oracle Corporation of Belmont f California, was 
based on the IBM System R, SQL. In 1980 f ORACLE was 
rewritten in "C". 

As of 1986 , ORACLE had been ported to about twenty different 
minicomputer vendors 1 hardware. It has been cited as having 
14.6% of the minicomputer DBMS market f thus making it the 
number one vendor of same. The development machine for the 
ORACLE product is the Digital Equipment Corporation's VAX 
minicomputer. 

ORACLE has recently been migrated to different sized hardware 
— mainframes and microcomputers. ORACLE is marketed as a 
user's DBMS, and uses SQL consistently throughout all its 
modules. As of Release 5, the modules which comprise ORACLE 
include: 

(1) SQL (for data definition); 

(2) SQL*Plus (for report writing and user queries); 

(3) Pro*ORACLE (for 3rd generation language interfaces); 

(4) SQL*Design Dictionary; and 

(5) SQL*Forms (for screen painting and online processes). 

Oracle Corporation's decision to rewrite its package in the 
"C" language has eased portability of the system. As systems 
programmers upgrade operating systems for users , however , 
there must be careful synchronization of the "C" compiler for 
ORACLE so that SQL statements perform in a standard fashion. 

As with DB2, ORACLE users notice that, as the complexity of 
transactions increases f response times slow (see discussion 
below) . This performance issue is also well known to vendors 
of third-party software which use ORACLE. In response, both 
IBM and Oracle Corporation are beginning to discuss microcode 
implementations of their product in future releases. This 
"turbo" feature bears watching as large prod' ion systems 
are developed. 



DB2 Us e in Industr y. In a 1987 Da tamation poll of IBM 
customers (Carlyle) , many corporations developing large-scale 
production systems in DB2 are "reluctant" to discuss them. 
The IBM Guide user group claims that over a thousand DB2 
licenses exist in the United States. 
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Seven large-scale operations which have been quoted as using 
DB2 in a production mode are: 

(1) DuPont; 

(2) Travelers Insurance Companies; 

(3) New York State Retirement Systems; 

(4) Metropolitan Life Insurance Company; 

(5) U.S. Navy Retail Logistics; 

(6) Deere and Company; 

(7) St. Paul Companies (medical liability insurers). 

DuPont employees refer to its use of DB2 for "strategic" 
aspects of the corporation. Travelers Insurance is on record 
as using DB2 for its "strategic" Customer Information Filr. 
The New York State Retirement System was a DB2 beta test site 
in 1984 f and currently quotes a database size of between 20 
and 30 gigabytes. U. S. Navy Retail Logistics is creating a 
large-scale DB2 prototype to test Texas Instruments software 
which automates the systems design process. 

Some statistics are available from these agencies regarding 
performance measures. The New York State Retirement System, 
for example, has quoted ten database calls per second with 
response times below three seconds. Deere and Co., by 
contrast, has noted that as transactions become more complex, 
response time slows significantly. 

Charles Schwab and Company performed a DB2 benchmark 
(QSW21i££L!dQJLl&, 1987) which found DB2 limited to 18 
transactions per second (tps) for their application. IBM 
quotes a 47 to 50 tps for production purposes. The source of 
this discrepancy, according to Schwab officials, is the 
record locking mechanism used within Release 2 of DB2: 
"...with 100 terminals, the locking became so extensive that 
DB2 crashed, along with CICS." 



fi£2JJS£-JlLJEda£ati<2D . The OASIS project, a research and 
development project currently underway by a consortium of 
IBM, Information Associates (IA) , and three campuses within 
the California State University System, has been approved to 
rewrite the IA Series Z software to operate under DB2. This 
is the only DB2-based production project within institutions 
of higher education discovered by this reviewer. The three 
campuses, CSU-Long Beach, CSU-Los Angeles and CSU-San Luis 
Obispo, have only begun the conversion of "Series Z" 
(currently written in COBOL) to SQL and DB2. Completion of 
the OASIS project is scheduled for 1990. 
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ORACLE Use in Industry. Although the ORACLE product has been 
on the market since 1979 f none of the technical/trade 
periodicals reviewed by this author carried articles 
regarding its use in industry. The publications of computer 
users' groups f however f did lead to several applications 
based in the ORACLE DBMS package. Three will be discussed 
here: (1) Byer of California; (2) Fritzi Corporation; and 
(3) Solomon Brothers. 

Byer of California and Fritzi are women's clothing 
manufacturers. The ORACLE DBMS is used by Byer for data 
definition and entry for their order processing system. 
Fritzi Corporation also uses ORACLE for their order entry and 
billing system. Both manufacturers are running their systems 
on Prime minicomputers. Screen definitions are not 
considered complex f and no performance problems have 
surfaced. Neither company is presently using SQL*Forros for 
screens in the production environment, but both are in the 
process of developing them. SQL has greatly enhanced their 
programmer productivity; both have fewer than ten programmers 
supporting their applications. 

Solomon Brothers, the financial management firm, as of the 
summer of 1987, uses the ORACLE DBMS in a production mode on 
four of its Prime minicomputers. They have also installed 
SQL*Forros on a fifth Prime, and are in the process of 
developing screen-based systems. 



ORACLE Use in Ed ucation . During the past si" months, several 
medium-sized universities have either implemented or begun 
development of ORACLE-based administrative software systems. 
The State Universities of West Virginia, for example, are 
beta testing the student information system package offered 
by Systems and Computing Technology, inc. (SCT) , which has 
just been rewritten in ORACLE. California State Polytechnic 
University, Pomona, has begun development of its student 
applicant system in ORACLE on a Prime minicomputer. A large 
university, San Francisco State University, has developed a 
Financial Aid application using ORACLE Release 5. This 
development is discussed next. 
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A 4GL PRODUCTION SYSTEM AT SAN FRANCISCO STATE UNIVERSITY 



In June, 1987, San Francisco state University received its 
copy of ORACLE Release 5 for installation on a Prime 9750 
minicomputer. Three months later, the ten-year-old 
(previously COBOL batch) production system was rewritten into 
an ORACLE database system, complete with online screens, 
reports and documentation. In January 1988, the system goes 
into test production in parallel with the old version, 
processing transactions from approximately 25 terminals. The 
test includes two new application modules beyond the scope of 
the original Financial Aid system. 

San Francisco State University (SFSU) is one of the nineteen 
California State Universities. With a headcount enrollment 
of 26,000, SFSU's Financial Aid recipients number over 
8,000. The decision to experiment- with a relational database 
management system for development of a Financial Aid 
application was strongly influenced by a grant of the ORACLE 
DBMS product from Prime Computer, inc. The auoted cost of 
ORACLE Release 5 exceeds $40,000. 

Among the great benefits of this development are user 
satisfaction and greatly enhanced programme! productivity. 
User requests for changes to tables (via the data dictionary) 
and screens can be implemented, for example, in less tha-.i a 
day. Among the drawbacks experienced by SFSU are costs of 
hardware upgrades and already visible response time 
degradation. 

During the four-month prototyping phase, SFSU has upgraded 
its hardware support for ORACLE Release 5 from a Prime 9750 
with eight megabytes of central memory to a Prime 9755 with 
14 megabytes of central memory. Prior to the upgrade, the 
four-person analyst team could "freeze" the minicomputer and 
bring down ORACLE by running four simultaneous processes. 
Counts of page faults per second during this test exceeded 
thirty. 

S-ftce our main student information system is on a different 
computer, we use a combination of SQL and COBOL to load and 
update the Financial Aid tables. This procedure currently 
requires over four hours of nightly batch runtime by the 
ORACLE system. 

Our most complex screens (developed using SQL*Forms) contain 
over 80 background processes. We have experienced up to ten 
second delays v/hile ORACLE processes screen input, runs a 
background COBOL routine (a third party Needs Analysis 
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ABSTRACT 

The advantages of using automated design tools to assist with 
the design of complete systems, individual applications, or data 
structures have been touted in the literature and by vendors over the 
past few years yet few CAUSE member institutions report using these 
tools today. A 1986 survey of 400 CAUSE member institutions found 
that of 186 respondents only 3% use automated design tools for systems 
design, 13% use them for applications design, and 10% use them for 
data structure design. This report will review the current status of 
automated design tool technology, and feature reports on the u^e of 
automated design tools by three CAUSE member institutions. 
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jL A REVIEW OF AUTOMATED DESIGN TOOLS 
PURPOSE AND SCOPE OF THE TOOLS 

Automated design tools are often collectively referred to as CASE 
(Computer Aided Software Engineering) tools. CASE can be viewed as 
CAD/CAM for codesmiths, or in the broadest definition as the automa- 
tion of anything a human does to software. Early (first generation) 
CASE was limited to graphics aids for the creation of data flow 
diagrams and structure charts, and various types of code generators. 
In much the same way that CAD/CAM has tied graphics to design metrics 
and engineering rules, CASE is integrating with other phases of the 
design life cycle, and automatically generating significant pieces of 
software and documentation. The degree to which the dream of auto- 
mated programming, or the "programmer in a box" notion can be realized 
is subject to dispute. Brooks notes that any system which can gener- 
ate code from specifications is forced to seek high levels of general- 
ization. "It is hard to see how such techniques generalize to the 
wider world of the ordinary software system, where cases with such 
neat properties are the exception. It is even harder to imagine how 
this breakthrough in generalization could occur." 

CASE tools are gaining popularity, and the scope of these tools con- 
tinues to increase. Maintenance concerns are being addressed by 
structured retrofit, data dictionary, and source code management pro- 
ducts. Debugging tools are becoming more sophisticated, and the 
graphics tools which we categorize most closely with CASE are con- 
stantly growing in features and usefulness. "Now, CASE tools are 
starting to link those squares and ovals to the logic of structured 
design methodologies. Not only can designers speed up the rote job of 
drawing diagrams, but they also can use CASE tools to perform basic 
error checking. Some of the more sophisticated CASE wares can check 
details, right dcwn through tree diagrams in which ^ach function is 
decomposed into more detailed elements." The reports in this paper 
demonstrate the wide scope of uses to which CASE tools are being put 
in three CAUSE member institutions. 

LIMITATIONS OF THE TOOLS 

There are some amazing stories of productivity increases due to the 
use of CASE tools. "..The application, which was originally expected 
to cost $268,000 was completed for a mere $30,000... We elected to use 
Application Factory for a 60-day trial and see what effect that would 
have on the overall project. We were surprized to find we coul^ get 
the whole project done in the 60-day trial with just two people." 

While boasts of great productivity increases in specific instances are 
interesting, most managers would like to have a more defensible metric 
for measuring changes in productivity. While many shops have no con- 
sistent moasure of software development productivity in place, a recent 
survey by Infosystems found that sixty nine percent of the respondents 
reported that they mearured programmer productivity, and that a sur- 
prising fourty .six percent of those reporting were using function 
point measures. It is interesting "hat several of the original pro- 
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ducers of CASE tools are now vending productivity measurement software 
and methodologies . 

The inability of CASE tools to help with program maintenance is a fre- 
quent complaint of new CASE users. "About two years ago we installed 
Pacbase, a comprehensive development system. Users were enthusiastic, 
and the project team was enthusiastic... We deinstalled it a year ago. 
Pacbase's maintenance works on applications developed^ with Pacbase, 
but for our existing systems we couldn't make it work. 11 

Another frequently limitation of CASE products is programmer accep- 
tance. "It's difficult to get developer s-the programmers and 
analysts-to use them. ..they don't see the tool as something that 
will increase their own marketability. Another reason is that all 
tools have some limitations. You get to a point where an application 
generator can't handle a particular problem. With the demand to pro- 
vide users with pgrfect customization, you wind up having to program 
in COBOL anyway." The level of integration of the components of a 
particular CASE tool with an installations existing DBMS and other 
software is also an item of frequent concern. Some software vendors, 
Software AG for example, are making significant strides in the in- 
tegration of automated design tools with their existing family of de- 
velopment and operational products. 



THE FUTURE OF AUTOMATED DESIGN TOOLS 



Automated design tools are currently offering meaningful assistance to 
software development, and three such instances are reported in this 
paper. Especially helpful is the data dictionary integration which 
offers a single, controlled repository for forms, screens, procedures, 
data definitions, and data element usage mapping. The functionality 
of automated design tools and data dictionary features is certain to 
continue to increase in quality. Artificial intelligence and expert 
systems advances may result in improved CASE tools. Some leading 
software engineers doubt if artificial intelligence will be of much 
help to software development. "...Most of the work is problem- 
specific, and^ome abstraction or creativity is required to see how to 
transfer it." Some experts believe that expert systems hold more 
hope for increasing programmer productivity and quality. "The most 
powerful contribution by expert systems will surely be to put at the 
service of the inexperienced programmer the experience and accumulated 
wisdom of the best programmers." 

The following reports show how three different automated design tools 
have been integrated into the design life cycle, and used to pro/ide 
meaningful improvements in the software development environments at 
three CAUSE member institutions. 



Ili BOSTON UNIVERSITY - AN IMPLEMENTATION OF PREDICT 
INTRODUCTION 



Boston University is an independent coeducational, nonsectarian un- 
iversity located in Boston, Massachusetts. The university has a full- 
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time equivalent enrollment of approximately 21,000 students and a fa- 
culty that numbers nearly 2,500. The University consists of sixteen 
schools and colleges and a medical campus. 

COMPUTING ENVIRONMENT 

University Information Systems provides the University f s main ad- 
minstrative information processing support. An IBM 3090-180 mainframe 
running under MVS is used for mainframe administrative systems. Work 
is underway to expand an existing local area network, currently con- 
necting most of the University f s academic locations, to the main ad- 
minstrative processing site. This expansion of the network will as- 
sist in the distribution of the University f s mainframe systems 
throughout the schools and colleges. 

PRODUCT OVERVIEW 

Predict is a mainframe data dictionary package, developed and marketed 
by Software AG. Predict is utilized with the database management 
system ADABAS and the fourth generation programming language Natural, 
both of which are also Software AG products. In the past, Predict has 
typically been used by organizations, such as Boston University, to 
record physical and logical representations (Userviews) of ADABAS 
files. Using Predict utilities, file definitions were generated to 
provide programmer access to ADABAS files. An additional use of 
Predict has been to document the data base environment by recording 
file and data element descriptions. 

FUTURE DIRECTION 

One of the future directions of Software AG is to more fully integrate 
their database products, while utilizing the Predict dictionary as a 
core system. Recent examples of this direction have included the 
introduction of a facility which, at the time program object code is 
generated, automatically records cross-reference information in the 
dictionary about the program, its processing components, (e.g. 
subroutines, maps) and the files and fields that they access. In 
addition, verification rules may now be recorded for data elements in 
the data dictionary and pulled into programs as a means of 
standardizing edits and reducing redundant coding. 

INTEGRATION WITH THE DESIGN LIFE CYCLE 

One of the Data Administration strategies utilized at Boston 
University is to integrate the data dictionary within all phases of 
the design life cycle. As a central repository for documenting the 
University f s data, the data dictionary should provide systems 
developers and end users with the ability to ob { ,in reliable 
information about the data and the functions availablj to access the 
data. By actively utilizing the data dictionary as a design tool 
throughout system development , the perception of system documentation 
as an obstacle to progress is avoided. Dictionary tools available 
through Predict are enhanced by inhousp. tailoring and extension of the 
data dictionary. They are also supplemented with software packages 
available for use with Macintosh personal computers. 
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Entity modeling is employed as one of the techniques to analyze data 
requirements, by graphically representing the organization's entities 
and the relationships between them. The fundamental rules about the 
the way in which data is used in the organization are also represented 
m these models. The use of this data modeling technique has proven 
to be very successful in promoting communication and in developing a 
common understanding of data. It also serves as a stable and lasting 
model of the organization, a basis for naming conventions and a 
first-cut representation of data base design. 

Once entity models are finalized, the entities are reflected in the 
data dictionary as entity files (refered to as "standard" type files 
in Predict). These entity files become the central source for data 
element names, attributes and definitions. The standard attributes of 
fields within entity files are copied forward to form the actual 
fields within ADABAS files as well as "userviews" of these files. 
This is used to ensure ongoing consistancy of data element attributes 
and it also allows data elements to be defined only once, in the 
entity file, regardless of the number of physical files in which they 
may eventually appear. 

Data element names are made up of an abbreviated form of the entity 
name, the domain class (e.g. identifier, flag, date, code, etc.) and 
one or more words to provide meaning. We have developed functions to 
support dictionary maintenance which check for use of standard 
abbreviations when new data elements are named. The abbreviation 
table used to support this function is also used to translate the 
abbreviated dat.a element names into full words within data dictionary 
reports. 3 

End users are actively involved in the development of entity models 
and in defining data elements, since they have the most complete 
business knowledge of the data. A modified version of the standard 
Predict functions has been assembled to support end user involvement 
throughout the system design life cycle. Included within the tailored 
data dictionary functions are options allowing documentation for 
files, fields, systems, functions and maps (screen layouts) to be 
recorr'jd. To support standardization, guidelines regarding the type 
of questions to be addressed by the documentation are provided as part 
of online dictionary functions. An interface is also included to a 
screen painting" facility which allows system developers and/or end 
users to jointly develop draft images of online screens during the 
system design process. The finalized screen layout is reflected as 
part of the lasting documentation for online functions. 

DISTRIBUTED INQUIRY AND MAINTENANCE 

The availability of accurate, informative and complete system 
documentation supports an organization-wi^e objective of distributing 
the functisnality of existing mainframe systems to University 
departments. The increased awareness of existing systems helps to 
reduce coscly duplication of both data and processing of data. 

The distribution of data dictionary maintenance is an issue which has 
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been addressed through developing multiple update profiles for the 
data dictionary. System developers are given a data dictionary 
maintenance profile which allows them to represent data req' irements 
for new files or modifications to existing files. This is 
accomplished through the creation of Predict "concept 11 files. The use 
of "concept" files allows system developers to analyze several design 
options while utilizing data dictionary tools to verify conformance 
with Data Administration standards. The creation of the physical 
ADABAS file and generation of logical views of this file are performed 
by Data Resource Management following a file design review process. 
This review process weighs factors such as flexibility, data 
redundancy, semantic clarity, efficiency, security, programmer ease of 
use, and ongoing data integrity to determine an optimum design . 

An additional data dictionary maintenance profile is provided to end 
users to promote their active involvement in the system design life 
cycle. This profile allows them to view existing file descriptions 
and to update definitions of data elements for which they are the data 
trustee. Both Data Administration and the data trustee must approve 
data element definitions before they are finalized within entity 
files* Various report options are also made available through this 
dictionary application to facilitate documentation review. 

NEW OPPORTUNITIES 

Data dictionary profiles are currently being enhanced to allow more 
extensive documentation to be recorded regarding systems, 
applications, online functio/s, programs and maps, in addition to 
files and fields. Relationships between online functions, the 
system(s) which they are part of, and relationships to sub-functions 
and programs invoked within functions may all be reflected in the data 
dictionary. The use of keyword/subject searching has also been built 
into this enhanced version to facilitate inquiries. In addition to 
supporting documentation of implemented University application 
systems, the capability to centrally document and analyze business 
models is regarded as a potential future use of the Predict data 
dictionary. As opposed to the entity model, which documents data 
relationships, the business model reflects important business 
activities of the organization including hierarchical relationships 
between business functions. 

As analysis progresses forward to file design, it is envisioned that 
information gathered in business modeling and translated into function 
specifications may be utilized to automate logical access mapping. 
This cross-referencing of functions and their data access 
requirements , combined with stati sties regarding anticipated frequency 
of function utilization, may be used as the basis for determining file 
design and assignment of file access keys. 

SUPPORT SERVICES 

In order to move in the direction of automating data analysis and 
database design, we have attempted to more formally integrate design 
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tools with our systems development methodology. A series of system 
life cycle checkpoints involving Data Resource Management, have been 
developed as guidelines for Project Leaders and Systems Analysts. A 
small internal committee, chaired by Data Administration, is currently 
in the process of formalizing these checkpoints and developing 
documention to support them. For each checkpoint, documentation will 
include: 

- brief description of the checkpoint 

- purpose 

- examples 

- involvement (who is responsible, participates and reviews) 

- procedure, including the level of detail 

- tips and techniques 



In addition, it is recognized that, at the commencement of every 
project, an evaluation of internal training needs should be conducted. 
Documentation from this Checkpoint Review Committee will be passed on 
to our internal training area as a basis for developing a training 
program. 

PRODUCT EVALUATION 

Without enhancement, the Predict data dictionary fails to meet many of 
our design related objectives. The cost of tailoring this package 
must be constantly weighed against the ability to provide improved 
support of both application staff and end user requirements. However, 
the close ties between Predict, ADABAS and the programming language 
Natural, which is utilized for nearly all new program development, 
provides a compelling opportunity to pull together the components of 
our development environment. We anticipate that our direct form of 
technical data dictionary support may be minimized in the future. To 
achieve this goal, we look forward to more powerful and flexible 
releases of the Predict data dictionary as well as the availability of 
improved mainframe and personal computer based design tools which 
ideally, will interface with the data dictionary. 



Ill- GEORGIA INSTITUTE OF TECHNOLOGY - AN IMPLEMENTATION OF WORKSHOP 204 
INTRODUCTION 

The Georgia Institute of Technology is a single-campus, state as- 
sisted university located in Atlanta, Georgia. Georgia Tech was 
founded in 1885 and is a unit of the University System of Georgia. 
The institution has an enrollment of over 11,000 students \n 
architecture, engineering, management and the sciences. itie 
undergraduate enrollment is approximately 8,500 and the graduate 
student enrollment is approximately 2,500. Georgia Tech ranks 
first among public universities in engineering research and develop- 
ment expenditures. 
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COriPUTING ENVIRONMENT 

Data processing software support for administrative users is pro- 
vided through the Department of Information Systems and 
Applications (ISA). Computer operations support is supplied by 
the Office of Computing Services (OCS). The campus is served by 
GTNET, an optical fiber network providing access to all 
computers. There are a number of mainframes available, 

including : 

1. Cyber 180-810 - 16 megabytes of memory and 1.55 
gigabytes of disk storage - Plato, CAE/CAD. 

2. Cyber 180-^30 - 16 megabytes of memory and 3.12 
gigabytes of disk storage - CAE/ CAP . 

3. Cyber 180-855 - 16 megabytes of memory and 15.88 
gigabytes of disk storage - Administration. 

4. Cyber 180-855 - 64 megabytes of memory - 
Academic/Student Usage - NOS operating system. 

5. Cyber 180-990 - 32 megabytes of memory and 24.6 
gigabytes of disk storage - Academic and 
Research - N0S-VE operating system. 

6. IBM 4381-R14 - 32 megabytes of memory and 45 gigabytes 
of disk storage - Administrative and General Academic 
- MVS operating system. 

7. IBM 4341 - 16 megabytes of memory and 7.5 gigabytes of 
disk storage - CAD/CAM. 

Most administrative student related computing is handled by 
Cyber 855 using the NOS operating system and DMS-170 Database 
Management System . 

Many administrative accounting functions are handled by a Cyber 855. 
MSA General Ledger, Accounts Payable and Budgetary Control packages 
and Information Associates Alumni Development System are resi- 
dent on the IBM 4381. The Model 204 Database Management 
System, under which a vehicle registration and citation 
processing system has been developed, as well as several small 
applications supplementing the MSA packages, runs on the 4381. 
Printing is handled by Xerox 9700 and 8700 laser printers, a high 
speed Cyber impact printer and distributed line printers. 

WORKSHOP/204, MODEL 204 DATABASE MANAGEMENT SYSTEM 

Descriptions of the product: 

WORKSHOP/204 is a collection of integrated tools designed to fa- 
cilitate the development of full-scale applications in a MODEL 204 
environment. MODEL 204 is the current, commercial version, of what 
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Computer Corporation of America called a "software system" when it 
was developed as an information storage ~d retrieval system in 1967. 
The name is derived from the term d " j -^del since MODEL 101 was one 
of the first implementations of an inverted data model. 
Initial development was funded by Pell Labs, which sought an ad- 
vanced data model for rapid access to large online databases. 
The MODEL 100 series which included MODEL 103, an interactive 
system under DOS, and MOD^.L 104, an interactive system under OS 
were not actively marketed, although the first sale was to the 
University of Illinois in 1969. In 1971, the product was 
significantly enhanced, renamed MODEL 204, and the first sale was 
made to the Department of Defense, 

MODEL 204 was developed specifically for an integrated, online 
database environment. An online, interactive System Command 
Language permits database structures to be created and modified 
dynamically. User Language is a complete database application 
development tool which truly can be used by both data processing 
and nondata processing personnel. The system's Resource 

Management Facilities pro ide the ability to dynamically monitor 
and adjust MODEL 204 f s performance. The database structure 
ensures data independence and maximum flexibility. The System 
Command Language, User Language and Resource Management Facility 
are all native to the MODEL 204 nucleus. In addition, the MODEL 
204 nucleus has direct interfaces to IBM's teleprocessing access 
methods: VTAM, TCAM and BTAM, which means less work in building 
an interactive application. 

Responding to the vicissitudes of commercial competition, CCA ac- 
quired and developed a number of products to assist in system 
development. DICTIONARY/204, PAINTER/204, ACCESS/204 and PC/2 04 

have been available since 1984. Several of these products and 
others have been brought together in WORKSHOP/204 - a product 
which, as advertised, integrates a collection of tools designed 
to facilitate the development of applications in a MODEL 204 
environment. It has been available since early 1986. 

WORKSHOP/204 offers facilities for: 

- Defining an application subsystem 

- Defining and prototyping databases and views 

- Generating screens and procedures to manipulate data 
in a view 

- "Painting" screens 

- Editing User Language code 

- Documenting applications 

- Creating test data 

- Testing 

Each WORKSHOP facility automatically documents its results in the dic- 
tionary. Programmers may invoke DICTIONARY/ 204 1 s 
Documentation facility through WORKSHOP to augment the system 
controlled dictionary data with their own descriptions. Subsystem 
Management: The subsystem management facility allows the developer 
to define a collection of User Language procedures to form a pro- 
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duction application requiring minimal end user knowledge of MODEL 
204. The developer enters information about the subsystem: files, 
procedures, error handling and security. The facility provides the 
driver and maintains its own error handling aid security. Sub- 
systems improve performance by saving and reloading compiled proce- 
dures defined to the facility as "precompilable" . 

File Management: Database definition is accomplished through the file 
management facility. The user enters information about file 
characteristics, field attributes, record layouts, and field 
groups. Based un information provided, the file is sized. 
Changes may be executed immediately or in a delayed batch mode. 
The dictionary entries and the MODEL 204 files they describe are 
synchronized . 

View Definition: Views are collections of logically related 
fields defined by the user from file definitions. View 
definitions specify the records and fields to be retrieved, how the 
data is to be displayed, display names or column headers, 
convenient width to be used and may include * lidation criteria. 
Different views may be relationally joined based on common field 
values to form a composite view. Views are used by the Screen 
and Action Generator, and the Query/Update facility. Views are 
also used by the query/report generator (ACCESS/204), and PC204, 
which permits retrieval, updating and data transfer between 
mainframe and personal computer, without having to write programs. 
Query /Update : This facility is a prototyping tool for developing 
MODEL 204 applications. Its use enables one to create, modify, 
query, and update views of data without actual file creation or 
programming, using a system-provided file, or to perform system 
prototyping using an existing MODEL 204 database. It also 
provides a means of populating a file with test data. 

Screen and Action Generator: Using a previously defined view, this 
facility generates a screen and "action" procedures which use the 
screen to manipulate data. The action supports querying, updating, 
displaying, and deleting of data. The generated procedures can 
be modified using Procedure Editor. The screens can be modified 
using Screen Painter. Screens and procedures generated may be used 
as building blocks of applications. 

Screen Painter: This facility is used to create and modify 
screens. The user "paints" the screen, then specifies screen item 
attributes. Screen Painter generates the User Language code whiv.h 
defines the screens described in this way. 

Procedure Editor: The facility enables the user to define pro- 
cedures and to edit User Language code with the full-screen editor. 
It supports Specifying characteristics of the editing sessions, 
such as mixed case or upper case and maintenance of aspects of the 
procedure definition, such as the aliases and the procedure security 
class . 

Documentation: The user may enter descriptive de ta to dictionary 
entries of any entity type. It is useful for expanding in- 
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formation stored with system-generated data and for adding data that 
is not system-controlled. 

Single-Step Test: Using this facility, it is possible to test ap- 
plications subsystems by stepping through User Language 
procedures with several options available between each step. The 
name of the next procedure to be executed may be viewed and 
changed, global variables may be viewed and changed, any 
procedure may be edited, a temporary request may be run, runtime 
statistics for each procedure may be displayed. 

As noted earlier, WORKSHOP/204, in addition to automatic updating of 
the dictionary, provides access to the facilities of 

DICTIONARY/204, the online interface to MODEL 204 f s dictionary. 

SPECIFIC USES OF THE PRODUCT 

As background for a discussion of Georgia Tech f s use of MODEL 204 and 
of our experience in using WORKSHOP/204, it should be noted that our 
acquisition of a database management system for use on the IBM 4381 
was a part of a long range plan for comprehensive institutional 
data management which included moving all administrative 
systems from the CYBERs to the IBM 4381. Progress in implementing 
that plan has been much slower than we orginally hoped it would be. 
We have been now for some time in a process of intense re-evaluation 
of existing systems, particularly in the area of the institution's 
business administration. The policy of the institution remains, how- 
ever, to purchase package software if adequate products are available. 
In-house systems development is limited to applications for which 
no satisfactory commercial product exists. That custom work which 
is done is primarily on small ancillary sytems. 

MODEL 204 was installed at Georgia Tech in November of 1985. The ini- 
tial system installed included PAINTER, DICTIONARY, ACCESS/204 
and Subsystem, the application subsystem management facility 
Our use of PAINTER, DICTIONARY and Subsystem has been extensive. 
WORKSHOP, which incorporates these ar * the other facilities 
described was not released until early 1986 and was installed at 
Tech in November 1986. 

The applications developed under MODEL 204 include a campus 
vehicle registration and parking system, inquiry to combined pur- 
chase order, invoice and check data, an accounts pcyable docu- 
ment tracking system, an interim alurmi development system and a 
general ledger/property control interface. 

PRODUCT INTEGRATION IN THE DESIGN LIFE CYCLE 

The vehicle registration portion of a proposed campus parking 
system was chosen r , a pilot project to be implemented on the 
system. Although ries gn work for such a system had been done 
earlier, a considerable amount of time wos spent working toward a 
data nr*del in third normal form. 
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It's only fair to the vendor, CCA, and to the product, to 
emphasize that ray comments in relation to our use of products now 
incorporated in WORKSHOP/204 describe our experience with earlier 
versions of them. While the names are the same, access to them 
is improved and the specific problems we encountered have been 
resolved . 

Files, records, fields and procedures were identified through DIC- 
TIONARY - an incredibly laborious task at the time. To enuer, or even 
accept the default attributes for a field, for example , it was 
necessary to progress through no less than six screens - and woe 
betide the f umble-f ingered person who made a mistake - it was impos- 
sible to return to a previous screen in the sequence. It was 
necessary to progress to the end, then re-enter the function 
(change a entry) to correct the error. The motivation for using DIC- 
TIONARY, however, was strong - not only was there a desire to use the 
facets of this product we had, but DICTIONARY provided the "Dat; l*ase 
Interface" function - which sized the file and produced the file par- 
ameters and field definition statements to be used in creating a new 
MODEL 204 file. This facility, of course, made use of the file, 
record and field definition entered in the DICTIONARY. So, to the 
inexperienced database manager, the drudgery of dictionary entry 
seemed a small price to pay for some built-in "professional" as- 
sistance in file creation. 

In addition, a long-term goal of our organization, rich in the ac- 
cumulated product of more than 25 years of student record and 
administrative data processing programming, was to define the 
"institutional data" in an online dictionary. This project 
offered an opportunity to display the potential benefits j n 
making use of such a facility. 

The ability to add user-defined entities to the dictionary is an ex- 
tremely useful feature. We made use of it to add further 
documentation, such as source of data, use, coding, format, 
initial content, editing, retention period and authority, which 
included manager, owner, custodian and user identification. PAINTER 
was also extensively used in development of the systems described. 
It's far easier * "paint" a screen, modify and re-modify it until it 
meets approval, nan it is to code statements, test, then code again. 
PAINTER provides a default set of screen attributes or allows at- 
tributes to be defined by the designer. Since we use color monitors, 
this was a feature pleasing to some who used the product. We experi- 
enced a high level of frustration at times due to inherent product 
problems (inability to correctly deal with a many-item screen, oc- 
casional gratuitous duplicate entries for screen items in the 
metadata file, for example) and d^e to lack of knowle-^e about rela- 
tion of the product to some "system" files (the wrath of a program- 
mer who has spent an hour or more designing a screen and laborious- 
ly defining attributes only to lose it all because a temporary file 
is full is a sight to behold). 



EVALUATION OF THE PRODUCT FOR PURPOSES USED 
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Despite problems with both products during the course of de- 
veloping the systems described, they surely contributed to pro- 
ductivity. Each of the systems described was developed by a dif- 
ferent person - each person working in a MODEL 204 environment for 
the first time (one in an IBM environment for the first time). 
The interval of time from assignment to release for production 
use in every case included the "What ! s M204, what f s User Language" 
period, system design, file design, screen design and roding. The 
fact that the simplest systems were up and running in 3 weeks, 
the more complex in four to eight weeks, speaks well for the 
useability of the products - and for the capabilities of o**r 
staf f ♦ 

WORKSHOP/204 which incorporates products with which we are fa- 
miliar, does improve ease of use of DICTIONARY and PAINTER. The 
other facilities provided, particularly the prototyping 
capability offered and the screen and action generator, should 
prove extremely useful. 

File and field definition, which is a function of DICTIONARY/204, is 
a much smoother and more efficient process in the version incor- 
porated in WORKSHOP. Field attributes, for example, may be defined 
on one screen, rather than the previous laborious process of moving 
through six screens for each individual field. 

PAINTER is more reliable. As with all the WORKSHOP products, it f s 
now possible to remain in one of the facilities, moving forward 
and back, until satisfied with the results before completing 
the function. Previously, once begun, the apparent assumption was 
that the user would progresj in an orderly fashion from start to fin- 
ish of any function - little recognition cf tl>e all too frequent 
failings of most us which cause us to benefit: from the opportunity 
to regroup and fix the oversight. 

FUTURE PLANS FOR 1HE USE OF AUTOMATED DESIGN TOOLS 

W:> plan to use WORKSHOP/ 204 facilities in the design and im- 
plementation of future administrative data processing support 
systems. We will make fuller use of prototyping because our 
limited experience proves its an invaluable tool in working with 
users to define the real *>roblem. Use of the WORKSHOP facilities 
for data definition, screen design and procedure coding has the 
overarching benefit of forcing a level, and certainly an 
immediacy, of documentation not previously achieved. 

Our experience after a recent series of in-house training ses- 
sions also indicates that WORKSHOP moves an inexperienced staff 
member much more quickly into product! a participation in the devel- 
opment cycle. I i the world of database design, for example, or at 
least in our world, there are myriad details to be considered in 

file design and field description - other than the familiar "what 
type, what size" situation. Being prompted to consider those 

details produces a better end result more quickly. 
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SUMMARY 

Does WORKSHOP/204 provide "paradise or promises 11 ? In Milton's 
words "The mind is its own place, and in itself - Can make a 
heaven of Hell, a hell of Heaven". In the minds of those who 
need to launch inexperienced staff members into rapid 
productivity in an unfamiliar system - and who wish to maintain a 
degree of documentation, extracted from those staff members only 
against their will, it comes close to providing a paradise. To 
those who have, by whatever means, struggled through a learning 
phase and achieved a degree of competence in dealing with the 
database and development under it, WORKSHOP/204 is one of those 
"user friendly" systems we're all familiar with - when you know 
what you want to do and how to do it, having to pass through 
voluminous numbers of optional question/answer items tries the 
patience of the most saintly. However, even the experienced 
person, committed to the principle of at least minimal 
documentation, will welcome the automatic dictionary update which 
WORKSHOP/204 provides. SCREENGEN, the applications screen and 

cede generator while perhaps most useful to newer users, also 
offers relief from basic design and coding to veterans. 

The product is a good one. It is useful - it delivers much of what 
it promises - particulaily if use is instituted at the outset of 
moving to a MODEL 204 database management system environment. 

IV. GREENVILLE COLLEGE - AN IMPLEMENTATION OF EXCELERATOR 



INTRODUCTION 

Greenville College has had a computer since 1978 and has developed 
all of the administrative software systems using College person- 
nel. During school year 1985-86, a decision was made to upgrade the 
computer hardware and to investigate different software systems. 
Several different software vendor's systems were evaluated and com- 
pared by the different functional offices of the College. A deci- 
sion was made to upgrade only the hardware usiig the same vendor that 
was already being used by the College. A Data General MV8000-II 
was ordered to be installed during the summer of 1986. This decision 
was based on several factors: 

1) Several of the functional offices were very happy v.ith the 
internally developed software and saw no improvement of 
their information needs by changing to some other 
vendor's software. 

2) Data General's academic software p ogram included software 
which would significately improve the administrative and 
academic uses of the computer on the campus. 

3) This would be the easiest change from one computer to 
another. All the data bases were dumped to tape and rebuilt 
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on the new computer and the program sources were dumped to 
tape, loaded on the new computer and recompiled. 

Part of the Data General software package included some com- 
ponents of automated system design tools. These include Data Dic- 
tionary, a Screen Generator, a Program Generator and a Source Man- 
agement System* Each of these components are seperate pieces of 
software and we found them v. ; weak in the areas of documen- 
tation, ease of use, user friendliness and linkage to each other. 



After several months of use and evaluation we determined that 
these components of automated systems design tools were not suffi- 
cient to do automated system design and implementation. We then de- 
cided to purchase an IBM PC/AT and also purchase the software 
package called Excelerator. The IBM PC/AT was purchased to implement 
a network with the other IBM PC computers which were already on 
campus, mostly in a computer science laboratory. Excelerator is 
one of several CASE tools which runs on the IBM PC/AT and Excelerator 
was choosen because of previous experience in using th*;- product. We 
knew of Excelerator 1 s capabilities and that our internal documenta- 
tion would greatly improved. 

USES OF THE PRODUCT 

The Excelerator product was first used in the re-development of an 
information system for the Admissions Office of the College* 
This system was completely designed by using Excelerator. 
When the design phase of the Admissions Systems was nearing comple- 
tion, we decided to enter the complete data dictionary of ell 
of the administrative systems for the campus into Excelerator 1 s 
repository. Additionally, in several major maintenance projects 
we have used Excelerator to develop better documentation from which 
the users have a better understanding as to how the changes will 
effect other processes and how the changes will be implemented. 

We are currently using Excelerator in all parts of our system 
development life cycle including new systems development and systems 
maintenance. During the summer of 1987 we changed the method of 
charging students. Previously we would wait until the last add/drop 
cut-off day and then charge all students their charges and apply 
some of the Financial Aid. We changed to a system of charging at 
the time of the enrollment line completion. 

Several functional areas of the College were involved but very few 
knew how the data intregrated to creat-e a student bill. With the 
assistance of Excelerator we were able to create documenta- 
tion which clearly defined and explained how these processes 
were performed . 

EXTENDED USES OF THE PRODUCT 

Excelerator is linked with WordPex-fect and with Harvard Total 
Project Manager. This gives the user of Excelerator the ability 
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to move to the other software products without retailing to the op- 
erating system. Data files can be transported from Excelerator 
to WordPerfect. Data Flow Diagrams, prototyping reports and 

screens, data stores, entity list, structure diagram are a fei T of the 
pieces of documentation which Excelerator can generate. The pieces 
of documentation from Excelerator and documentation from both Har- 
vard Total Project Manager and WordPerfect help us make better 
presentations to users and give both users and the designers a 
better understanding of the information requirements of the different 
systems being developed. 

Excelerator is also being used in course work assignments in a 
systems design class which is a part of the computer science major 
offered at Greenville College. Members of this course must design a 
system of some kind and several members of the course select 
projects which will become a part of the administrative system of 
the college. Some of systems which have been developed using Ex- 
celerator include: 

1) College Work Study Accounting System 

2) Purchase Order Entry 

3) En cumber en ce Reporting 

FUTURE USES OF THE PRODUCT 

Ws have decided to use Excelerator as a repository for our corpo- 
rate data dictionary. We have loaded information about all of the 
financial/accounting functional information systems elements and 
all of the student information systems elements into the product. 
There are still other areas of ou**, information system which need to 
be loaded into Excelerator. We plan to do all future system devel- 
opment using the Excelerator product and feel that this would 
give us a better way to manage our corporate data dictionary. 
We also envision the possibility that we may change the vendor of our 
main computer or even add mulitple computer vendors. We feel that 
we can more easily move our data from our current software to oth^r 
software, another hardware vendor or even add multiple computer 
vendors and still be able to manage our data dictionary without 
converting our data dictionary to some other software/hardware 
format. We are uploading some information from Excelerator to out 
Data General MV8000-II to assist in the program development process. 
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